The application services would allow fully functional Turbine applications
to be packaged up in the form of JAR files and deployed during Turbine
Turbine would probably process a directory of JAR files
that contain sub-applications. The manifest would contain
a set of instructions to be used by the application service
so that the sub-application would be processed correctly
and usable by Turbine. This may be the module.packages
to add, or template paths to add, or whatever else is
needed to bootstrap the sub-application.
Module packages have to be dynamically configurable.
The assembler broker must accept additional packages
to look in for modules after the system has started.
Must be able to load templates from JAR files. Velocity
can do this, and it can probably be done for the other
template services as well.
Configuration information must be able to enter a
running Turbine application. A sub application might
have many forms of configuration info. It might be properties
that have to be accessible via TurbineResources. Or
it might configuration information to be used by one
of the services, say for example an intake XML descriptor
for the input forms used in the sub-application.
The services in general might need some work to allow
dynamic configuration so that sub-applications can
really work properly.
Sub-applications may require certain operations to be
executed in order to run. This might be a forum application
that has an SQL schema that needs to be inserted in order
to function. These stops could either be performed by Ant,
or scripts that could be executed by the proposed BSF
(Bean Scripting Framework) service.
Sub-applications will require a unique id to to keep things
like templates in their own namespace. Eventually there
may also be other entities that need to be kept separate.
We could probably start a catalog of sub-applications to
make sure that people don't use a unique id already being
used by another sub-application in existence.
Extension do DynamicURI and derivates to support new parameter