<?xml version="1.0"?>
<!-- 
/*
 * Copyright 2001-2004 The Apache Software Foundation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 *      http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
 -->

<document>

  <properties>
    <title>Application Service Proposal</title>
  </properties>

<body>

<section name="Description">
  <p>
    The application services would allow fully functional Turbine applications
    to be packaged up in the form of JAR files and deployed during Turbine
    startup.
  </p>
</section>

<section name="Rationale">
<p>
</p>
</section>

<section name="Requirements">
<ul>
  <li>
    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.
  </li>

  <li>
    Module packages have to be dynamically configurable.
    The assembler broker must accept additional packages
    to look in for modules after the system has started.
  </li>
  
  <li>
    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.
  </li>

  <li>
    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.
    <p/>
    The services in general might need some work to allow
    dynamic configuration so that sub-applications can
    really work properly.
  </li>
  
  <li>
    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.
  </li>

  <li>
    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.
  </li>

  <li>
    Extension do DynamicURI and derivates to support new parameter
    (sub-application selector)
  </li>
</ul>
</section>


<section name="Scope">
<p>
</p>
</section>

<section name="Initial Source">
<p>
</p>
</section>

<section name="Initial Committers">
<p>
</p>
</section>

</body>
</document>
