On Sun, 28 Oct 2001, Stefano Mazzocchi wrote: > giacomo wrote: > > > Sometimes it is good if you have pressure from real work which suck time > > you'd like to give to OS projects. Afterwards you'll usually have new > > power and ideas to rejoin the community. I speak from experience and I > > also think Stefano can confirm it ;) > > Absolutely, dude! :) > > Ok, Giacomo raised the issue again and it's time to do something to > resolve something and decide where we are going. > > So, from now on, we can use the [STATUS] in mail messages to indicate > summaries that allow people to keep up. > > Status files should be simple and selfcontained so that everybody can > grasp it without having to read thousand lines of RT or mail digests. > > So, here we go. > > - o - > > There are three main areas that require architectural changes: > > 1) pipeline assembly and control > 2) dynamic XML production > 3) deployment of cocoon-powered sites and web applications > > Pipeline assembly and control > ----------------------------- > > The first area is currently covered by the sitemap that includes > instructions on how to define components, assemble the pipelines and > control their operations. > > A few limitations were observed: > > a) it mixes concerns: it is hardly possible for a non-programmer to > become a sitemap designer/maintainer.
This is IMHO the main problem > b) flow isn't obvious: the sitemap was designed around a request > matching paradigm which is great for publishing but fails short for more > complex web applications. Agreed. > c) the use of code generation and compilation increases load time and is > believed not to increase runtime performance due to hotspot removal. There are other reasons for eliminating code generation and compilation like complexity which the javac imposes, or easier reloading strategies. > d) mostly due to c) and further implementation details, sitemaps cannot > be cleanly nested and components inherited. Well, this is due to the existance of the CodeFactory interface which IIRC is eliminated in the HEAD branch. > Possible solutions to the above problems were proposed: > > 1) avoid code generation and aim to fast tree-traversal algorithms. It > is likely to increase memory use but it would remove both c) and d) > problems. +1 This doesn't mean that I've changed my mind in regards of rewriting the current sitemap semantics from a currently compiled into a interpreted one. Sure, I wouldn't stop any volunteer doing so but my vote on this will be -0. > 2) two proposals were submitted along the very rough "flowmap" concept > that Stefano outlined some months ago. They are: > > a) Berin's [fixme - indicate mail URL] > b) Daniela's and others at levigo.de [fixme - indicate mail URL] > > The two solutions aim both to solve both a) and b) and make it easier to > use Cocoon to write web applications and to separate the concerns > actually mixed by the current sitemap design. > > Solution a) is not back compatible and requires semantic changes to the > sitemap while solution b) is back compatible and may be added today. I don't prefer either one. The proposal from Berin is IMHO a new approach and will have another learning curve than the on from Daniela, which I've grasp immediately (more or less :) > Possible direction would be to let volunteers implement solution b) to > earn more information that could be applied to a major new back > incompatible Cocoon release (maybe 3.0 or so). +1 > Dynamic XML production > ---------------------- > > Note that I didn't say "generation" because it could happen at both > generation and transformation stages. > > This part is currently achieved by manual writing of pipeline components > (generators or transformers) or by the use of XSP or JSP technology, or > the use of other scripting languages. > > While the solution to manually create components will always remain, > this is suitable only for ad-hoc solutions that require lots of > programming logic and very few static content (just like servlet vs. > JSP, so to speak). > > While the use of JSP or other scripting languages (jpython, PHP) is > possible, XSP is currently the most advanced solution but, again, it > mixes concerns. > > Proposals are: > > - x:forge (opensource.bibop.it) > - DXML (Ricardo's project) > - SAXlets (levigo's project) > > Ok, you guys add more comments if you need to. There is still some thought in my mind about dbXML (or other XML DBs) which could result in a new protocol for a Source of XML. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
