cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: TODO List so far
Date Tue, 31 Oct 2000 10:41:29 GMT
Sylvain Wallez wrote:
> 
> Hi folks,
> 
> I had a few ideas while reading Giacomo's todo list that I wanted to
> share. I'm relatively new to Cocoon (3 months) and started to study C2
> only 2 weeks ago so forgive me if these ideas are not relevant, and if
> not please explain me why.

Sure thing.
 
> Giacomo Pati a écrit :
> >
> > Hy all
> >
> > Here is my todo list I've collected so far.
> >
> 
> <snip/>
> 
> > - Cache Proposal
> >      There has been a discussion many weeks ago about this topic.
> >      We need to take up again to come to a conclusion. There has
> >      been some thought about that from Russ Burton IIRC.
> >
> 
> A problem I think in both C1 (Modifiable) and C2 (Changeable) is that
> objects implementing these interfaces have no mean to say they will
> *always* change (volatile, no ergodic period). Don't know for C2, but in
> C1 (that was discussed recently on the list) the URL of an XSP is
> blocked while its content is produced to be put after in the cache. This
> is useless, since hasChanged() always returns true (unless you redefine
> it in the XSP), and has the additional bad side-effect of blocking
> concurrent requests to the same URL ! Also, I don't understand in which
> condition the C2 XSPGenerator modifiedSince() method can return false
> (it returns true if the XSP creation date is before the current date).

The C1 cache system is extremely poor in that detail (look at my inner
comments in Engine.java) and the behavior should be interface driven: if
the XSP doesn't want to be cached, it simply doesn't implement the
caching interfaces.

This was not possible before and this is the reason why XSP 1.1 will
have specific caching semantics. Ricardo will explain that in his paper.

> So can a new "isVolatile" method in "Modifiable" be the solution (if
> isVolatile, don't even try to cache it) ? What do you think about it ?

Nah, don't need that.. the cache will look if the generator/transformer
implements the cacheable interface and attemp to cache it if does,
otherwise do nothing and call it directly.
 
> Also, for objects that do have an ergodic period, I noticed in C1 that
> the cache key is the request URL and browser type. Don't we need a more
> generic mechanism based on the object model ? For example, I have some
> applications where XSPs can be cached on a per-session or per-user
> basis. Since I have no mean to express it, they're always regenerated.
> And I think this particular point will arise often with
> content-aggregation portal-like pages.

This is correct, the Cocoon caching interface should have access to the
whole object model so to allow perfect caching granularity.

The only problem with this approach is that caching the serialized
output becomes a configuration nightmare... more on this on my caching
proposal. stay tuned.
 
> >
> 
> <snip/>
> 
> > - Moving sitemap component to cocoon.xconf
> >      Peter Donald (Avalon) mentioned recently to move the
> >      <map:components> section from the sitemap.xmap to the
> >      cocoon.xconf file. This indeed would reduce the verbosity of
> >      the sitemap but also will introduce some restrictions to the
> >      design we have today. One restriction is that the concept of
> >      the CodeFactory (direct integration of java code during the
> >      sitemap generation stage) will not be possible anymore. Also
> >      if someone uses many "custom" components to build up his URI
> >      part its not been seen in "his" sitemap and the responsable
> >      person of the cocoon.xconf file (usually a sysadmin) will
> >      have to be contacted if new sitemap components have to be
> >      integrated. Please discuss this as well.
> >
> 
> Regarding this point, why not use XInclude for the sitemap and xconf ?
> That would allow parts of their contents to be defined elsewhere.

Yes, I thought about that as well, but I don't see this as a big issue
right now.
 
> This suggestion comes from personal experience : some of our customers
> are big companies where people that are responsible for the installation
> and tunig in production environment (sysadmins) know nothing about the
> application. And these people like to have a single file that contains
> all runtime parameters they have to configure (JDBC info, LDAP server
> address, logins, etc). Also, mixing runtime information with structural
> information (definition and composition of components) in a single file
> can easily lead to application breakage if some structural information
> is accidentally changed when setting runtime parameters.
> 
> Well, isn't that a kind of separation of concerns ? But the problem is
> that the elements that define these concerns heavily depend on the
> context : knowledge and responsibilitites of people, application,
> customer, etc. So I think using XInclude may be useful to achieve this
> separation in a modular fashion.

Totally agree, in fact, even Apache has an include directive in
httpd.conf and it's very useful.

+1 for adding XInclude semantics to the sitemap.
 
> > So far these are the items I've collected during my break and the ApacheCon. I
> > know there might be others issues which are not listed above, so please stand up
> > and bring it into this discussion.
> >
> > After we have collected all of them we will have to prioritize them and
> > categorize them to state which will be suitable for Beta 1.
> >
> > Ok, let's start it.
> >
> 
> One additional item that was discussed recently : allowing classes
> produced from XSP to extend other classes than XSPGenerator. This would
> allow XSP to be used as a generic langage for XML generation in
> environments where a servlet context is not useful nor available
> (database connectors, legacy file transformation, etc) without
> reinventing the wheel and rewriting all the complicated java generation
> stuff.

Yes, XSP 1.1 will abstract completely on what is generated and dynamic
transformers will be available. True, this will greatly overlap with
XSLT, but I don't care, the users will define who wins.
 
> Hope you will find these suggestions usefull.

Totally, keep it up :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



Mime
View raw message