giacomo wrote:
> > The main purpose is to switch from a code-generation approach to an
> > interpreted one. IMO, code generation is most usefull when the language
> > offers an exit point to the target language like in JSP and XSP but
> > unlike sitemap. XSP also can be extended using logicsheets by people
> > with medium XSLT knowledge.
>
> I don't see this as the main purpose. The main purpose IMHO is to switch
> from a sitemap approach as it is today with many concern overlaps to a
> more concern separated approach with URI-maps, flowmaps, statemaps (or
> whatever there will be next). This means we have to decide about the
> architecture first. If the implementation of it will be interpreted or
> compiled is a question of technology to be choosen and comes at
> second place.
I resonate more with Sylvain's and other's vision on this than with
yours, to be entirely honest.
In fact, I see two different issues on the table right now:
1) pipeline assembly and control semantics
2) pipeline assembly and control implementation
The two are different concerns and they must be kept separate.
> > Sitemap is a different problem. It's not an optional component like XSP,
> > but the main processor of incoming requests. If this processor isn't
> > pluggable in Cocoon, this strongly reduces the possibility of trying
> > other approaches. The first step is thus to update it to be a
> > first-class component like all others in cocoon.xconf. This was done
> > just today (see my commit this morning).
>
> I've seen it and I like it. Good work.
>
> But now we have to stop and discuss or vote if we need an additional
> interpreted version of the sitemap. I think we'd better discuss how a
> better approach will look like and implement that architecture instead
> of implementing the same sitemap with the same flaws again but with a
> different technology.
Incremental evolution works better in open-source. We all have to
understand this, even if it seems to sacrifice some architectural
elegance at first.
I myself would like to have both:
1) a better sitemap/flowmap/statemap design
2) a better implementation of it
but, we have to do both and we have to start someplace. I see no harm in
letting people provide pluggable versions of the "pipeline controls"
(let's call it this way to avoid having to rename them all the time) and
let them play with it.
I personally would wait for 1) to be finished before doing 2), but some
people do it the other way around, learning by coding and we shouldn't
stop them from trying if they want to.
Of course, as long as they understand that they may be implementing a
moving target.
> > Also, sitemap.xsl is a wonderful demonstration of what can be done in
> > XSLT for generating code. I was really impressed when I discovered both
> > the power of the sitemap langage and the way it is implemented. But it
> > requires strong XSLT knowledge to anybody wanting to extend it. This
> > again restricts the possible experiments on new approaches.
>
> Yes, of course and I (as the creator of this implementation of the
> sitemap) always thought it was an experiment to see how good the
> markup2code engine is. Nobody else had further developed the interpreted
> version (and in the early beginnings of Cocoon version 2 there was a
> interpreted version from Pier).
I remember weaking up on a sunny sunday morning and finding Giacomo
paper-coding the sitemap engine right there at my place (Giacomo and
Ricardo were my guests that time).
At that time, it seemed to me as the best technological achievement
ever, expecially given that such a complex system took a couple of weeks
to implement.
I still believe there is a lot of room for xslt-generation of
programming code (look at Gump, for example), but I agree that it
requires non-conventional programming skills and we can't base our core
engine on that.
Moreover, I'm curious to see how long would it take for somebody that
really wants to do it, to reimplement the sitemap with an interpreted
version and compare the same imlementations performance and scalability
wise.
> > Having
> > sitemap logicsheets would have allowed this a bit, but you told once
> > this wasn't encouraged even if the program generator infrastructure
> > supports it.
>
> Can you imagine what happened then? I wasn't in the mood to support that
> and I'm sure many people would need the support if we encouraged
> peoples to use logicsheets for tha sitemap.
Oh, god. Yes, this is another reason to make it harder to people to mess
around with the core engine.
> > All this to say that the interpreted sitemap can be considered as a
> > starting point for the implemention of others ways of processing
> > requests. And since it's now pluggable through cocoon.xconf, it can
> > smoothly co-exist with the current compiled sitemap.
>
> As I've said above let us have the sitemap as it is today and let us
> join our forces on a new approach instead of building the same sitemap
> semantics based on a different technology.
I don't think that if somebody volunteers to rewrite the current
compiled implementation with an interpreted one, this is going to slow
us down or remove energy from the design process of the new semantics.
Rather the opposite, it would profide implementation feedback on
proposed solutions, right when he/she has the hand dirty with code.
> I say that also because if we
> need to change semantics in the sitemap we have to change it in the
> interpreted as well as in the compiled version. We already know how
> often we missed to submit changes on the esql.xsl into version 1 and
> version 2 cvs repos. Can you imagine that someone willing to change the
> semantic of the sitemap is likely to change both sitemap techonolgy
> pieces?
I think you misunderstood the intentions: the idea is to rewrite the
"current" semantics without changes, totally back compatible (this is a
"must" goal for now) and it's going to provide information on the
compilation/interpretation approach for speed, scalability, memory use
and all that.
This has *nothing* to do with sitemap semantics, it's an entirely
different concern and nobody wanted to mix it.
> No, I definitively don't like the co-existance of two semantically the
> same achitecture implemented with different technologies into the same
> system.
Why so? what harm does it do?
The current sitemap semantics is *not* going to change overnight since
we are planning a major revamp, but we'll probably shoot for 3.0 or
something.
I would love to have Cocoon 2.1 with an interpreted version of the
existing sitemap, instead, because it would make it easier, once we
defined the new "pipeline controls", to implement it.
Moreover, in Daniela's proposal, an interpreted version of the sitemap
was almost required and I'd love to have an incremental path toward 3.0
rather than a stepwise solution like we did for between 1.0 and 2.0.
Sure, users will be warned that some semantics it's going to change, but
they know this anyway.
I'm currently shooting for the least-friction path to more complete
"pipeline controls", but ramping up two concerns at the same time
(design and implementation), I'd love the evolutionary path to be:
1) Cocoon 2.1 -> interpreted sitemap
2) Cocoon 2.2 -> semantically compatible flowmap addition
.... -> subsequent changes
3) Cocoon 3.0 -> statemap (redesign of sitemap/flowmap combined)
which guarantees a much easier transition, a much better cooperation of
newcomers, and a much easier implementation of technologies since more
small steps are easier to follow than few big steps.
But of course, this is only my personal view and comments and
suggestions are welcome.
--
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]
