CVS update of julia/src/org/objectweb/fractal/julia (overview.html)

[Lionel Seinturier <seintur@xxxxxxxxxxxxxxxxxxxxxxxxx>]

    Date: Monday, October 30, 2006 @ 15:40:32
  Author: seintur
    Path: /cvsroot/fractal/julia/src/org/objectweb/fractal/julia

Modified: overview.html

Typos.
First elements of a new section on component-based control membranes added.


---------------+
 overview.html |   63 +++++++++++++++++++++++++++++++-------------------------
 1 files changed, 35 insertions(+), 28 deletions(-)


Index: julia/src/org/objectweb/fractal/julia/overview.html
diff -u julia/src/org/objectweb/fractal/julia/overview.html:1.3 
julia/src/org/objectweb/fractal/julia/overview.html:1.4
--- julia/src/org/objectweb/fractal/julia/overview.html:1.3     Mon Oct 30 
15:20:03 2006
+++ julia/src/org/objectweb/fractal/julia/overview.html Mon Oct 30 15:40:32 
2006
@@ -36,7 +36,8 @@
 <a href="#5">5 Mixin classes</a><br>
 <a href="#6">6 Interceptor classes</a><br>
 <a href="#7">7 Class generation framework</a><br>
-<a href="#8">8 Support for constrained environments</a><br>
+<a href="#9">8 Support for constrained environments</a><br>
+<a href="#9">9 Component-based Control Membranes</a><br>
 <a href="#A">A Mixins reference</a><br>
 <a href="#B">B Optimizations</a><br>
 </blockquote>
@@ -46,8 +47,8 @@
 Julia is France Telecom's implementation of the Fractal Specification.
 This document describes the design choices made to implement Julia, the
 organization of Julia's source code, and the main algorithms and data
-structures used in Julia. This document is intended for framework developpers
-that want to extend Julia, but it can also be useful for component 
developpers
+structures used in Julia. This document is intended for framework developers
+that want to extend Julia, but it can also be useful for component developers
 that want to understand how Julia works. The reader is supposed to be 
familiar
 with the Fractal Specification.
 
@@ -62,7 +63,7 @@
 configuration to dynamic reconfiguration: we want to provide a sufficiently
 rich and flexible set of control objects, so that the user can make the
 speed/memory tradeoffs he or she wants. In particular, this set of control
-objects must allow the user to instantiate non reconfigurable but very 
efficent
+objects must allow the user to instantiate non reconfigurable but very 
efficient
 components or, on the contrary, completely reconfigurable but less efficient
 components. It must also allow the user to mix these components, in order to 
use
 different optimization levels for the different parts of an application. The
@@ -366,7 +367,7 @@
 users would not be able to apply new aspects to the existing Julia classes 
(in
 order to add new control aspects that crosscut existing ones).
 
-<p>What is needed to really solve our modularity and extensiblity problem is
+<p>What is needed to really solve our modularity and extensibility problem is
 therefore a kind of AOP tool or language that can be used at load time or at
 runtime, without needing the source code of the base classes, such as
 <a href="http://jac.objectweb.org";>JAC</a> (Java
@@ -389,8 +390,7 @@
 href="http://www.disi.unige.it/person/LagorioG/jam/";>JAM</a>, would be 
written
 as:
 
-<pre>
-mixin A {
+<pre>mixin A {
 
   inherited public void m ();
 
@@ -404,8 +404,7 @@
 
 is written in Julia in pure Java, as follows:
 
-<pre>
-abstract class A {
+<pre>abstract class A {
 
   abstract void _super_m ();
 
@@ -420,14 +419,13 @@
 In other words, the <tt>_super_</tt> prefix is used to denote the
 <tt>inherited</tt> members in JAM, i.e., the members that are required in a
 base class, for the mixin class to be applicable to it. More precisely, the
-<tt>_super_</tt> prefix is used to denote methods that are overriden by the
-mixin class. Members that are required but not overriden are denoted with
+<tt>_super_</tt> prefix is used to denote methods that are overridden by the
+mixin class. Members that are required but not overridden are denoted with
 <tt>_this_</tt> (a mixin class cannot contain a <tt>_super_m</tt> method if 
it
 does not have a corresponding <tt>m</tt> method. Likewise, a mixin class 
cannot
 have both a <tt>_this_m</tt> method and a corresponding <tt>m</tt> method):
 
-<pre>
-abstract class M implements I, Countable {
+<pre>abstract class M implements I, Countable {
 
   int _this_f;
   abstract void _super_m ();
@@ -455,8 +453,7 @@
 (each required method and field may be provided by a different mixin). For
 example, if N and O designate the following mixins:
 
-<pre>
-abstract class N implements I {
+<pre>abstract class N implements I {
 
   abstract void _super_m ();
   abstract void _super_n ();
@@ -486,8 +483,7 @@
 (note that this class implements all the interfaces implemented by the
 mixin classes):
 
-<pre>
-public class ONM implements I, Countable {
+<pre>public class ONM implements I, Countable {
 
   // from O
   public int f;
@@ -523,8 +519,7 @@
 
 while the mixed class O M N is the following class:
 
-<pre>
-public class OMN implements I, Countable {
+<pre>public class OMN implements I, Countable {
 
   // from O
   public int f;
@@ -566,8 +561,7 @@
 instantiated directly). A mixed class can be declared as follows in the Julia
 configuration file:
 
-<pre>
-(onm
+<pre>(onm
   (org.objectweb.fractal.julia.asm.MixinClassGenerator
     ONM
     org.pkg.O
@@ -604,7 +598,7 @@
 corresponding to the given "aspect" code generators.
 
 <p>Each "aspect" code generator can modify the code of each application 
specific
-method arbitralily. For example, an "aspect" code generator A can modify
+method arbitrarily. For example, an "aspect" code generator A can modify
 the method <tt>void m () { impl.m() }</tt> into:
 
 <blockquote>
@@ -770,7 +764,7 @@
 
 As explained in section <a href="#2">2</a>, one of the goals of Julia is to 
be
 usable even with very constrained JVMs and JDKs, such as the KVM and the J2ME
-librairies (CLDC profile). This goal is achieved thanks to the following
+libraries (CLDC profile). This goal is achieved thanks to the following
 properties:
 <ul>
   <li>the size of Julia runtime (35KB, plus 10KB for the Fractal API), which 
is
@@ -795,6 +789,19 @@
   with this API.</li>
 </ul>
 
+<h2><a name="9"></a>9 Component-based Control Membranes</h2>
+
+<p>Since version 2.5, the control membrane of a component can be implemented 
+with an assembly of so-called control components. This feature which were 
+originally developed for
+<a 
href="http://fractal.objectweb.org/tutorials/aokell/index.html";>AOKell</a> 
+has been ported to Julia. This new feature does not modify any of the 
existing 
+elements of the Julia framework: existing applications run unmodified and 
the 
+various features of the framework up to advanced ones such as intra and 
inter 
+components optimizations (see appendix <a href="#B">B</a>) are still 
supported 
+without any modification. This code of this new feature can be found in the 
<tt>
+org.objectweb.fractal.juliak</tt> package and its sub packages. </p>
+
 <hr><h2><a name="A"></a>A Mixins reference</h2>
 
 <h3>A.1 Mixins for the <tt>Component</tt> interface</h3>
@@ -928,7 +935,7 @@
   <tt>BindingController</tt> implementation in order to skip 
<tt>Interface</tt>
   objects, which removes one indirection for each binding of the component 
(the
   <tt>bindFc</tt> method of this mixin stores the server interface argument 
in
-  an internal hash table, and calls the overriden method with the "impl" 
link of
+  an internal hash table, and calls the overridden method with the "impl" 
link of
   this server interface as argument, instead of the server interface itself; 
the
   other methods are modified accordingly).</li>
 
@@ -1015,7 +1022,7 @@
   is updated by associated interceptor objects.</li>
 
   <li><tt>OptimizedLifeCycleController</tt> provides an implementation that
-  works ony with composite components, and that does not requires associated
+  works with composite components, and that does not requires associated
   interceptors. This implementation works by stopping simultaneously all the
   direct and indirect primitive sub components of the composite 
components.</li>
 </ul>
@@ -1025,11 +1032,11 @@
 extends an existing <tt>LifeCycleController</tt> implementation in order to
 check type related constraints before starting a component (more precisely, 
this
 mixin checks that all the mandatory client interface of the component and of 
its
-direct and indirect sub components ar bound). Finally the
+direct and indirect sub components are bound). Finally the
 <tt>ContainerLifeCycleMixin</tt> extends existing 
<tt>LifeCycleController</tt>
 implementation in order to notify the component's content when it is started 
or
 stopped, through its <tt>LifeCycleController</tt> interface, if it is present
-(this mixin is intendend for "container" components).
+(this mixin is intended for "container" components).
 
 <h3>A.9 Mixins for the <tt>NameController</tt> interface</h3>
 
@@ -1258,4 +1265,4 @@
 <tt>OptimizedCompositeBindingMixin</tt></b>
 </center>
 </body>
-</html>
+</html>
\ No newline at end of file