cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Content aggregation
Date Wed, 04 Oct 2000 15:00:08 GMT
Niclas Hedhman wrote:
> 
> Stefano Mazzocchi wrote:
> 
> >                         -------------- o -------------
> >
> > Ok, now we have aggregated content.... what do we do with it?
> >
> > We have to style it.
> 
> This is the hardest part, I believe.

Yep.

> A single aggregated resource, possibly dynamically generated, has the need
> for the ability to split into a bunch of HTML pages, such as a Framed
> Layout.

This is very tricky but it can be done... see below.
 
> > Smart, isn't it?
> >
> > There are two different style concerns: area placing (layout) and
> > content adaptation (style). Normally, the two things are done by
> > different people: the layout writer is not usually an artist, but it's
> > more a user interface designer that looks at different locations for
> > information and understand where the things should work best.
> >
> > >From the most simple web site to the most complex portal, layout is a
> > fundamental part of every 2D interface: newspapers invented the idea of
> > 2D layout and visual design patterns... while the "look" of the page is
> > defined by the style, the "feel" of the page is defined by its layout.
> >
> > Cocoon must therefore allow these concerns to be separated.
> >
> > How? well, let's try to come with a reasonable solution... we now we
> > have a highly orthogonal document which contains n+2 namespaces where n
> > is the number of aggregated resources (each resource to be aggregated
> > *MUST* output a namespace, this will be absolutely required and Cocoon
> > might signal an error in case no namespace is present to avoid
> > collisions)
> >
> > (+2 'cause of the xlink and structure namespace)
> >
> > ok, let's see...
> >
> >  <generate type="aggretator">
> >   ...
> >  </generate>
> >  <transform src="/www/graphics/fancy/structure2html.xsl"/>
> >  <transform src="/www/graphics/fancy/navbar2html.xsl"/>
> >  <transform src="/www/graphics/fancy/doc2html.xsl"/>
> >  <serialize type="html"/>
> >
> > where
> >
> >  - structure2html generates the layout frame and copies all the other
> > namespaces
> >  - navbar2html stylizes the navbar but leaves all the rest untouched.
> >  - doc2html does the same thing for the doc
> 
> Right!!
> My gut feeling is that this is possibly much harder than it first seems,
> especially if you drop in the cache aspect of it on top. But let's drop
> that for a second.

I've extensively thought about that and I think there are two things we
can do to make C2 fast enough for real-life use even in these complex
cases:

 1) internal cache
 2) proxy friendly behavior

If we assume we run under a HTTP/1.1 container (which is more or less
always the case), we have several methods to be proxy friendly and
reduce load.

The C2 cache will work more or less like the C1 and C1 cache has proven
very successful so far to increase req/sec values.

> It is not enough to have a Aggregator combined with general-purpose
> Transformers. The Aggregator does not know if the aggregated result will be
> broken into many pieces or not, only the Transformation + Serialization
> package has that knowledge. I have the feeling that this concept needs to
> be introduced to the sitemap, not only for Aggregation, but also for other
> usage. It is a bit related to branching the SAX and feeding more than one
> pipeline.

You forget a simple thing: HTTP works in pull, you can't push resource
to it.
 
>  <generate type="aggretator">
>   ...
>  </generate>
> <branch>
>     <dyn-resource>
>         <transform resultID="titlebar"
> src="/www/graphics/fancy/titlebar2html.xsl"/>
>         <serialize type="html"/>
>     </dyn-resource>
>     <dyn-resource>
>         <transform resultID="sidebar"
> src="/www/graphics/fancy/sidebar2html.xsl"/>
>         <serialize type="html"/>
>     </dyn-resource>
>     <dyn-resource>
>         <transform resultID="content"
> src="/www/graphics/fancy/content2html.xsl"/>
>         <serialize type="html"/>
>     </dyn-resource>
>     <dyn-resource>
>         <transform resultID="stockchart"
> src="/www/graphics/fancy/data2chart.xsl"/>
>         <serialize type="svg2png"/>
>     </dyn-resource>
>     <dyn-resource resultID="structure" >
>         <transform src="/www/graphics/fancy/structure2html.xsl" />
>         <serialize type="html"/>
>     </dyn-resource>
> </branch>

Hmmmm...
 
> And that the branch handler will be a virtual response handler, saving the
> serialized content to temporary storage and feed each of the dyn-resources
> with the resultIDs of the other dyn-resources as parameters to each of
> them. (Cyclic dependencies makes it more interesting :o) )

Ah, you save them for later.... hmmmm.

Give me some time to digest that.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message