cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [C2] Help offered
Date Tue, 27 Mar 2001 19:27:02 GMT
Simon George wrote:
> 
> Hi folks,
> 
> I've been silently observing the cocoon project for a while now and feel its
> time to contribute something back.  I have quite a bit of experience with
> Cocoon 1 and have used it in a couple of successful projects, but Cocoon 2
> seems to offer a real step forward.  I think I've now reached a suitable
> level of familiarity with the design concepts and architecture of Cocoon 2 -
> hence this email.

Good.

> Perhaps someone could suggest some areas that need more design/coding help.
> We have specific requirements  for content aggregation, intelligent caching
> and content syndication - some of which I gather are under development at
> the moment.

Any help is welcome. You exactly step into an area we still are thinking
about how to solve. There were several mail concerning exactly that (if
you are a lurker for a longer period you'll know that :).

Content aggregation and caching as I see it goes hand in hand. My last
points thinking about it is that the ResourcePipeline class need some
refactoring first to achieve all the above.

We need to separate the serialisation of a pipeline out of the
ResourcePipeline class. That way we can look at an assembled
ResourcePipeline as being an compound Generator. Having
ResourcePipelines without serializers enables us to cached it in its
hole and we can also report to the cache system if it has changed as a
hole (asking all the component that make up the ResourcePipeline).

The cache system as proposed by Stefano and Ricardo seem to me too big
to implement in one step. This is why I've suggested to implement the
cache for Generators only (I think there we will gain the most cache
efficency, but I could be wrong). 

Looking at content aggregation the last proposal suggests using
xinclude. The proposal states that an xinclude:href attribute points to
an cocoon internal resource if no protocol is specified. I think we
still need to discuss this issue because I can see difficulties when
bringing subsitemaps into play. Into which URI space is an xinclude:href
pointing? Into the root URI space the main sitemap controlls or into the
same URI space the sitemap controlls which issued the xinclude:href
reference (possibly a subsitemap mounted on a sub URI space of the root
sitemap). 

Maybe you have some ideas how to solve the one or the other issue here.

> 
> I've been extremely impressed with the standard of design and coding that's
> been done so far.  

Thanks.

> I hope I can live up to your high standards !

Don't worry. Go straight ahead.

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message