cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: xml-cocoon/xdocs cocoon2.xml
Date Mon, 14 Feb 2000 00:57:52 GMT
stefano     00/02/13 16:57:52

  Modified:    xdocs    cocoon2.xml
  wiser sentence
  Revision  Changes    Path
  1.2       +30 -27    xml-cocoon/xdocs/cocoon2.xml
  Index: cocoon2.xml
  RCS file: /home/cvs/xml-cocoon/xdocs/cocoon2.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- cocoon2.xml	2000/01/27 03:46:03	1.1
  +++ cocoon2.xml	2000/02/14 00:57:52	1.2
  @@ -26,7 +26,7 @@
     emerge. Today, most web engineers consider XML as the key for an improved web
     model and web site managers see XML as a way to reduce costs and ease
     <p>In an era where services rather than software will be key for
     economical success, a better and less expensive model for web publishing will
     be a winner, especially if based on open standards.</p>
  @@ -40,7 +40,7 @@
     detailed knowledge on the APIs available as well as underestimation of the
     project success, being created as a way to learn XSL rather than a full
     publishing system capable of taking care of all XML web publishing needs.</p>
     <p>For the above reasons, Cocoon1 was based on the DOM level 1
     API which is a <em>passive</em> API and was intended mainly for client side
     operation. This is mainly due to the fact that most (if not all!) DOM
  @@ -48,19 +48,19 @@
     practical for small documents and thus good for the &quot;proof of
     concept&quot; stage, it is now considered a main design constraint for Cocoon
     <p>Since the goal of Cocoon2 is the ability to process
     simultaneously multiple 100Mb documents in JVM with a few Mbs of heap size,
     careful memory use and tuning of internal components is a key issue. To reach
     this goal, an improved API model was needed. This is now identified in the SAX
     API which is, unlike DOM, event based (so <em>active</em>, in the sense that
     design is based the <em>inversion of control</em> principle).</p>
     <p>The event model allows document producers to trigger producing
     events that get handled in the various processing stages and get finally
     formatted in the response stream. This has significant impacts on performance
     and memory needs:</p>
       <dt>incremental operation</dt>
  @@ -97,7 +97,7 @@
         be identified earlier and their optimization performed better.
       <dt>reduced garbage collection</dt>
  -    <dd> 
  +    <dd>
         even the most advanced
         and lightweight DOM implementation require at least three to five times
         (and sometimes much more than this) more memory than original document
  @@ -108,7 +108,7 @@
         will always have performance and scalability impacts.
     <p>The above points, alone, would be enough for the Cocoon2
     paradigm shift, even if this event based model impacts not only the general
     architecture of the publishing system but also its internal processing
  @@ -124,13 +124,13 @@
     flexible way. In fact, opposed to the fixed pipe model used up to Cocoon
     1.3.1, the reactor approach allows components to be dynamically connected,
     depending on reaction instructions introduced inside the documents.</p>
     <p>While this at first seemed a very advanced and highly
     appealing model, it turned out to be a very dangerous approach. The first
     concern is mainly technical: porting the reactor pattern under an event-based
     model requires limitations and tradeoffs since the generated events must be
     cached until a reaction instruction is encountered.</p>
     <p>But even if the technical difficulties are solved, a key limitation
     remains: there is no single point of management.</p>
  @@ -142,14 +142,14 @@
     of them managing small amount of personal information, it becomes impractical
     for highly centralized information systems where distributed management is
     simply not practical.</p>
     <p>While in the HTML web model the page format and URL names
     where the only necessary contracts between individuals to create a world wide
     web, in more structured information systems the number of contracts increases
     by a significant factor due to the need of increased coherence between the
     hosted information: common style, common design issues, common languages,
     server side logic integration, data validation, etc...</p>
     <p>It is only under this light that XML and its web model reveal
     their power: the HTML web model had too little contracts to be able to develop
     a structured and more coherent distributed information system, reason that is
  @@ -157,20 +157,20 @@
     indexing and knowledge seeking. Lacks that tend to degrade the quality of the
     truly distributed web in favor of more structured web sites (that based their
     improved site structure on internal contracts).</p>
     <p>The simplification and engineering of web site management is
     considered one of the most important Cocoon2 goals. This is done mainly by
     technologically imposing a reduced number of contracts and place them in a hierarchical
     shape suitable to replace current high-structure web site management
     <p>The model that Cocoon2 adopts is the &quot;pyramid model of
     web contracts&quot; which is outlined in the picture below</p>
     <figure src="images/pyramid-model.gif" alt="The Cocoon2 Pyramid Model of Contracts"/>
     <p>and is composed by four different working contexts (the rectangles)</p>
  @@ -194,9 +194,9 @@
         presentation, look &amp; feel, site graphics and its maintenance.
     <p>and five contracts contexts (the lines)</p>
       <li>management - content</li>
       <li>management - logic</li>
  @@ -217,25 +217,28 @@
     management and debug complexity. Another overlapping in context contracts is
     the need for URL-encoded parameters to drive the page output. These overlaps
     break the pyramid model and increase the management costs.</p>
     <p>In Cocoon2, the reactor pattern will be abandoned in favor of
     a chain mapping technique. This is based on the fact that the number of
  -  different contracts is limited even for big sites (for example, even if the
  -  pages are millions, they probably all share no more than a few different DTDs
  -  and each DTD has no more than a couple of stylesheets).</p>
  +  different contracts is limited even for big sites and grows with a rate
  +  that is normally much less than its size.</p>
     <p>Also, for performance reasons, Cocoon2 will try to compile
     everything that is possibly compilable (pages/XSP into producers, stylesheets
     into processors, etc...) so, in this new model, the <em>processing chain</em>
     that generates the page contains (in a direct executable form) all the
     information/logic that handles the requested resource to generate its
     <p>This means that instead of using even-driven request-time DTD
     interpretation (done in all Cocoon1 processors), these will be either compiled
     into processors directly (XSLT stylesheet compilation) or compiled into
     producers using logicsheets and XSP which will remove totally the need for
     request-time interpretation solutions like DCP that will be removed.</p>
  +  <note>Some of these features are already present in latest Cocoon 1.x
  +   releases but the Cocoon2 architecture will make them central to its new
  +   core</note>
   <s1 title="Pre-compilation, Pre-generation and Caching">
  @@ -244,14 +247,14 @@
     constraints since it appeared in later versions. The issue regards static file
     caching that, no matter what, will always be slower than direct web server
     <p>To be able to put most of the static part job back on the web
     server (where it belongs), Cocoon2 will greatly improve it's command line
     operation, allowing the creation of <em>site makefiles</em> that will
     automatically scan the web site and the source documents and will provide a
     way to <em>regenerate</em> the static part of a web site (images and tables
     included!) based on the same XML model used in the dynamic operation version.</p>
     <p>It will be up to the web server administrator to use static
     regeneration capabilities on a time basis, manually or triggered by some
     particular event (database update signal) since Cocoon2 will only provide
  @@ -260,7 +263,7 @@
     generated in Cocoon2 via the servlet operation and cached internally or
     pre-generated and served directly by the web server, as long as URI contracts
     are kept the same by the system administrator (via URL-rewriting or aliasing)</p>
     <p>Also, it will be possible to avoid on-fly page and stylesheet
     compilation (which make debugging harder) with command line pre-compilation
     hooks that will work like normal compilers from a developer's point of view.</p>

View raw message