Hosted Development

Zero Alive Wiki

The initial goal is to provide sMash modules and documentation that enable users to setup a hosted development environment.

Stages:

1. Hosted development; single server; no remote deployment; embedded Derby (when data needed)
2. + remote deployment
3. + multiple servers in the hosted development environment
4. + other databases

Characteristics:

• One user per workspace; teaming is achieved through a SCCS

Principle components:

• User/workspace provisioning
• Dynamic proxy/port assignment
• App Builder
• Other?

Next steps

• ISL team will apply their changes to the latest AB code, then commit the updates to a branch in SVN; AB team will review and integrate
• ISL will review list of AB features needed to make AB "remote friendly" (e.g. file upload)
• Decide how to manage port assignments with dedicated AB
• Decide how to construct proxy URIs for applications within the hosted dev env

User/workspace provisioning

Dedicated application; fully contained within one sMash module (zero.alive) Will

Dynamic proxy/port assignment

Apache + mod_proxy; re-configured based on the assigned port

URI for mapping consists of user and app name; need to enhance (a user can have more than one application of the same name)

Port assignment currently rewrites the config file

How does this work? Can we link with Mandar's work around mod_proxy?

App Builder

AB should support localhost (no auth) as well as remote (auth required).

What enhancements were made to AB for ZA?

• show username, logout
• specific workspace root
• security.policy
• port assignments

Shared or dedicated?

Shared requires changes to account for user workspaces.

shared is more efficient; what about updates?

TODO: Deepak How would this change for dedicated ABs?

process.groovy : assigns ports. Needs a global view across all applications; easier in a shared AB.

Other

How to change password?

In a teaming scenario, how would a user checkout then open an app? Need a command prompt that's independent of any application.

For now, these are bugs that block bug 5438. After the roadmap is determined, we'll split bug 5438 into phases and divvy up the blockers accordingly.

bug_id	priority	bug_status	resolution	short_short_desc	status_whiteboard

Remote deployment

How should this work? Publish module to the repo; create linkto on the system (or update on subsequent changes) ?