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.
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.
c) the use of code generation and compilation increases load time and is
believed not to increase runtime performance due to hotspot removal.
d) mostly due to c) and further implementation details, sitemaps cannot
be cleanly nested and components inherited.
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.
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.
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).
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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
