Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BDC64E6.242C2E17@anyware-tech.com>
Date: Sun, 28 Oct 2001 21:04:54 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: RT - Tree Traversal Implementation of Sitemaps and XSP
References: <Pine.LNX.4.33.0110272231540.1824-100000@lapgp.otego.com>
 <3BDBF019.8C54F917@apache.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Stefano Mazzocchi a �crit :
> 
> 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.

Thanks, Giacomo :)

> > 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.

I also agree that it would be better to make 1) before 2). But the
recent discussions on flowmap showed that many people have great ideas
on this subject, and are experimenting things the way they can with the
current engine : mainly actions pointing to a separate flow engine,
which isn't satisfactory.

A Processor engine with easy plugging of new pipeline assembly
primitives would allow fast prototyping of new ideas within a common
framework. IMO, this can allow us to quicker stabilize the moving target
that we're all aiming at (flowmap/statemap/whatever).

> > > 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).

Ah, memories... ;) It's good to meet IRL.

> 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.

I know this problem : we use a lot of XSL here for generating plenty of
things : Java, SQL, other XSLs, etc. But XSL isn't a language for
"programming in the large" and large stylesheets are harder to maintain
than large Java classes.

> 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.

I'm working on it. I don't have much time dedicated for that, so time
won't really be significant. Deprecating CodeFactory and componentizing
the sitemap were the first steps.

> > > 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.

That's also a reason for an easily extensible 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.

Totally agree (see above).

> > 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.

Exacly. The goal is to implement the exact same semantic, but with an
extensible engine. It will certainly have to evolve with the thoughts on
pipeline controls, but this will be a starting point.

> > 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.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------

Sylvain.

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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