DPML Notify

[mcconnell AT dpml.net]

Author: mcconnell AT dpml.net
Date: Wed Apr 13 01:16:03 2005
New Revision: 2274

Added:
   development/central/site/src/docs/about/notepad/freight/observations.xml
      - copied, changed from r2271, 
development/central/site/src/docs/about/notepad/freight/issues.xml
Removed:
   development/central/site/src/docs/about/notepad/freight/issues.xml
Modified:
   development/central/site/src/docs/about/notepad/freight/development.xml
   development/central/site/src/docs/about/notepad/freight/index.xml
   development/central/site/src/docs/about/notepad/freight/navigation.xml
   development/central/site/src/docs/about/notepad/freight/recommendations.xml
Log:
complete the freight-train notes

Modified: 
development/central/site/src/docs/about/notepad/freight/development.xml
==============================================================================
--- development/central/site/src/docs/about/notepad/freight/development.xml   
  (original)
+++ development/central/site/src/docs/about/notepad/freight/development.xml   
  Wed Apr 13 01:16:03 2005
@@ -505,7 +505,7 @@
       <p>
       While the current development effort is looking promising there 
       are number of issues still to addressed.  These topics are covered
-      in the <a href="issues.html">following section</a>.
+      in the <a href="observations.html">following section</a>.
       </p>
 
       </subsection>

Modified: development/central/site/src/docs/about/notepad/freight/index.xml
==============================================================================
--- development/central/site/src/docs/about/notepad/freight/index.xml   
(original)
+++ development/central/site/src/docs/about/notepad/freight/index.xml   Wed 
Apr 13 01:16:03 2005
@@ -36,13 +36,15 @@
       </p>
 
       <p>
-      Out of this comes some <a href="issues.html">interesting questions</a> 
-      concerning the Metro development direction.  These include the 
effective
+      Out of this is a set of <a href="observations.html">observations</a> 
+      concerning the FT development status.  On one hand we have the 
effective
       disappearance of a framework in preference to a pattern driven 
approach, 
-      some rather interesting observations concerning configuration and 
-      parameterization and who/what is actually responsible for this, and 
-      a few unanswered questions concerning semantic around execution 
-      strategies.
+      some rather interesting side-effects concerning management, some 
+      questions concerning the role of configuration and parameterization 
and 
+      who/what is actually responsible for this, and a few unanswered 
questions 
+      concerning semantic around execution strategies.  Before leaping on 
the 
+      freight train its work looking through the list of obsavations and 
issues
+      to get a better idea of where were are and what needs to be done.
       </p>
   
       <p>

Modified: 
development/central/site/src/docs/about/notepad/freight/navigation.xml
==============================================================================
--- development/central/site/src/docs/about/notepad/freight/navigation.xml    
  (original)
+++ development/central/site/src/docs/about/notepad/freight/navigation.xml    
  Wed Apr 13 01:16:03 2005
@@ -25,7 +25,7 @@
     <menu>
       <item name="Brainstorming" href="brainstorming.html"/>
       <item name="Development" href="development.html"/>
-      <item name="Issues" href="issues.html"/>
+      <item name="Observations" href="observations.html"/>
       <item name="Recommendations" href="recommendations.html"/>
     </menu>
   </body>

Copied: 
development/central/site/src/docs/about/notepad/freight/observations.xml 
(from r2271, 
development/central/site/src/docs/about/notepad/freight/issues.xml)
==============================================================================
--- development/central/site/src/docs/about/notepad/freight/issues.xml  
(original)
+++ development/central/site/src/docs/about/notepad/freight/observations.xml  
  Wed Apr 13 01:16:03 2005
@@ -7,9 +7,124 @@
   <body>
     <section name="Freight Train">
 
+      <subsection name="Observations">
+
+        <ol>
+          <li>speed
+            <ol>
+              <li>FT is at least 300% faster than classic</li>
+            </ol>
+          </li>
+          <li>size
+            <ol>
+              <li>runtime (composition layer) codebase is about 20% of 
classic</li>
+              <li>buildtime codebase (type and component generator tasks) is 
about 70% of classic while packing a lot more functionality as class 
introspection is simply more efficient than javadoc tag handling</li>
+              <li>note - auto-assembly functionality not included in FT</li>
+            </ol>
+          </li>
+          <li>impact
+            <ol>
+              <li>buildtime validation is absolutely great - if something 
goes wrong is normally a build time error</li>
+              <li>build exception reporting needs to be enhanced (not clear 
where an error is coming from when you have nested components</li>
+              <li>runtime error reporting is good but logging management but 
on the other hand it feels a lot less important as a result of the strong 
buildtime validation</li>
+            </ol>
+          </li>
+        </ol>
+
+      </subsection>
+
       <subsection name="Issues">
+        <ol>
+          <li>logging manager
+            <ol>
+              <li>transit or metro</li>
+              <li>refactoring to use java.util.logging</li>
+            </ol>
+          </li>
+          <li>configuration and parameters
+            <ol>
+              <li>some work remaining to be done</li>
+              <li>safe to assume that config and params are immutable supply 
and forget artifacts (i.e. any runtime modification of a component would be 
through the context manager by the enclosing system)</li>
+            </ol>
+          </li>
+          <li>type and part viewers
+            <ol>
+              <li>FT does not provide an XML view of a type or part</li>
+              <li>can be addressed with a totally separate ant task - could 
be used to generate documentation about a component type and/or part 
automatically</li>
+            </ol>
+          </li>
+          <li>assembly logic
+            <ol>
+              <li>all assembly directives are explicit</li>
+              <li>need to add an assembly system in order to validate the 
explicit assembly instructions</li>
+              <li>deployment and decommissioning ordering will be required 
when handling serialized models which in turn requires a deployment graph</li>
+            </ol>
+          </li>
+          <li>intergrate with Transit server mode
+            <ol>
+              <li>Transit provides a server mode which triggers the setup of 
a reference transit instance.  It is desirable to launch metro in server mode 
and direct cli requests to the remote metro instance.</li>
+              <li>Server mode should be backed by an ant task that basically 
fires commands to a remote metro instance.  Such a task could be used as part 
of a deployment test framework.</li>
+            </ol>
+          </li>
+          <li>a <code>Manager</code> inner interface
+            <ol>
+              <li>Thinking is needed about a <code>Manager</code> inner 
interface within a component.</li>
+              <li>Seems to be the right place for a component to publish 
instrumention info it makes available.</li>
+              <li>Execution semantic are not currently handled.</li>
+            </ol>
+          </li>
+          <li>context manager development
+            <ol>
+              <li>More trials with <code>ContextManager</code> are needed to 
sort some of the details out.</li>
+              <li>Currently no validation on the <code>ContextManager</code> 
return type - but this is in effect a constraint declared by a container of 
the potential component that may be added as parts.  This constraint needs to 
be handled as part of the component part creation task.</li>
+              <li>Implementation of the context manager invocation handler 
needs more work - specifically, we need to clone the model context entries 
and resolved values into the per-instance context table enabling a complete 
context model view (current implementation just exposes the modified 
values).</li>
+            </ol>
+          </li>
+          <li>default parts creation and parts management
+            <ol>
+              <li>Packaging of default part with a component (e.g. 
[classname].parts) is required.</li>
+              <li>The &lt;type&gt; task needs to be updated to include the 
part association or we could put in place a .parts serialized object 
colocated with the class.</li>
+              <li>Parts builders need to updated to load and check for 
pre-declared default part entries.</li>
+              <li>The PartsManager is not currently implemented (however, it 
is expected that this will follow closely the general approach used for 
context management.</li>
+            </ol>
+          </li>
+          <li>integration between FT and classic
+            <ol>
+              <li>Need to update system context to load FT by default in no 
deployment targets are provided.</li>
+              <li>If the target is classic metro then bootstrap the classic 
composition otherwise bootstrap FT.</li>
+              <li>With an FT manager we could wrap classic with a dedicated 
controller - we could also do the same thing for Avalon 4 but this needs to 
be demand driven.</li>
+              <li>But ultimately would should be working on the assumption 
concurrent maintenance of classic and FT should be temporary and that final 
numbered build of classic should be a milestone target following which we 
would freeze the classic codebase and continue with FT as the Metro 
codebase.</li>
+            </ol>
+          </li>
+          <li>classloader handling needs to move down to transit
+            <ol>
+              <li>FT contains a specialized classloader with debugging 
support.</li>
+              <li>This should be moved down to Transit as part of the 
net.dpml.transit.repository package.</li>
+            </ol>
+          </li>
+          <li>model serialization
+            <ol>
+              <li>model serialization is not implemented yet</li>
+              <li>serialized models is central to the delivery of 
continuations</li>
+            </ol>
+          </li>
+          <li>documentation
+            <ol>
+              <li>FT makes most of our technical documentation 
redundant.</li>
+              <li>New tutorials are needed and documentation updates are 
required across the board.</li>
+              <li>Lots of opportunities exist for additional tasks the load 
parts and generate documentation automatically.</li>
+            </ol>
+          </li>
+        </ol>
+
+      </subsection>
+
+      <subsection name="Recommendations">
 
-        <p>IN PREPARATION</p>
+        <p>
+        The next section address <a 
href="recommendations.html">recommendations</a> based 
+        on the current development status.
+        </p>
 
       </subsection>
 

Modified: 
development/central/site/src/docs/about/notepad/freight/recommendations.xml
==============================================================================
--- 
development/central/site/src/docs/about/notepad/freight/recommendations.xml 
(original)
+++ 
development/central/site/src/docs/about/notepad/freight/recommendations.xml 
Wed Apr 13 01:16:03 2005
@@ -9,7 +9,22 @@
 
       <subsection name="Recommendations">
 
-        <p>IN PREPARATION</p>
+        <ol>
+          <li>consolidate current development and try to integration of FT 
within classic</li>
+          <li>get a final number build of metro classic out the door on the 
basis that the build will also mark freeze of the classic codebase</li>
+          <li>shift FT code into the main Metro development strategy
+             <li>build task enhancement</li>
+             <li>lots more testcases</li>
+             <li>added tools and utilities</li>
+             <li>trials on active deployment into a running metro 
instance</li>
+             <li>start thinking about IDE support for component patterns and 
pattern validation</li>
+          </li>
+          <li>rebuild magic's index/module logic somewhere along the 
line</li>
+          <li>completion of the FT codebase (see <a 
href="observations.html">issues</a> list)</li>
+          <li>migrate planet components</li>
+          <li>documentation and tutorials</li>
+          <li>articles</li>
+        </ol>
 
       </subsection>