cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Wed, 24 Oct 2001 20:09:17 GMT
On Sat, 6 Oct 2001, Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
> >
> > Peter Royal a écrit :
> > >
> > > At 12:31 PM 10/5/2001 +0200, you wrote:
> > > >Here I have the feeling we are doing the same mistake over again: the
> > > >sitemap was compiled when no hotspot tecnique was present and we had to
> > > >avoid excessive use of esternal recurrent logic when we could "unroll"
> > > >the tree traversal and let java execute it directly by transforming it
> > > >in code.
> > >
> > > I think the sitemap is really metadata that configures the cocoon engine.
> > > So in that respect are we mixing concerns by converting metadata into
> > > program code?
> > >
> > > I took your previous words about the removal of hotspots and applied those
> > > to our XSP pages in house. Before I was recreating the same java code
> > > repeatedly. As an answer to the hotspot issue, I moved the code into a
> > > separate class file with static methods, just like many of the internal
> > > logicsheets.
> > >
> > > I mention this because maybe we could apply some of the same techniques to
> > > the sitemap? Rather than generating a bunch of different methods, etc,
> > > could we not just compile the sitemap to a bunch of static variables
> > > (metadata) with method calls to do the actual work? Thus gaining some of
> > > the benefits of hotspotting? That might provide a migration plan towards a
> > > more radical design. It might also be
> > >
> > > As more and more people come on board using version 2, we need to protect
> > > the investment people are making in the current sitemap model. At least
> > > from the standpoint of providing a seamless transition to what is next, in
> > > both functionality and brain power required to understand.
> >
> > The transition is assured by using the same syntax, and I'm not sure it
> > would have to be changed with an interpreted engine. The only
> > compatibility break would be for CodeFactory selectors and matchers :
> > those ones would have to be rewritten as regular components. So I think
> > an interpreted sitemap engine could integrate smoothly in the current
> > architecture.
>
> Correct.

No, I don't think we should spent time and resources in an interpreted
sitemap engine, but rather in a new approach for dealing with the
concerns.

>
> > The problem is different for XSP : the language contains primitives such
> > as <xsp:page language="xxx">, <xsp:logic>, <xsp:expr>, etc, which
are
> > inherently related to the notion of programming language. I use the same
> > approach as yours for logicsheets (static methods), which along with
> > XSP-code size reduction, eases debugging a lot !
>
> Yes. XSP pages that contain <xsp:logic> tags will not be easily
> interpretable and will remain there for back compatible issues until

And <xsp:logic> are mixing concerns as well.

> *everybody* agrees better solutions have emerged and all of them have
> migrated to them.

And thus componentizing those stuffs that might get replaced by or
migrated over to other techniques is top.

>
> > There has been recently some long threads about alternatives to XSP,
> > mostly based on introspection transformers (see also x:forge at
> > opensource.bibop.it). Those may be easier to use than XSP (I wish java
> > had a #LINE directive like good old C compilers to set line numbers in
> > the generated class files !), but could hardly be as fast because of the
> > use of introspection.
>
> I've worked with the people at Bibop (many of which are on this list and
> one of them, Gianugo Rabellino, their former CTO, has already donated
> code to us) and they showed me some numbers indicating that their
> x:forge engine was actually faster than the XSP version.
>
> This showed me the evidence of the 'unrolled loop' thing I previously
> explained.
>
> So, I'd remove this "hardly" and say that a component-based approach
> (similar to taglibs) for dynamically created XML which uses runtime tree
> traversal instead of precompilation *might well* be as faster than XSP.

As faster than XSP ;)

>
> Ricardo, formerly senior engineer at Bibop, has already implemented an
> evolution of X:Forge which is a similar approach but is entirely based
> on namespace reaction. He's currently buzy doing some real-life work,
> but I believe we'll have some XSP alternative (hopefully faster and
> easier to use) in a short time, I'd shoot for Cocoon 2.1

Cool.

Giacomo

>
> > > I have been enjoying the recent RT threads though. I do appreciate that
> > > such discussions take place out in the openness of the dev list. Of course
> > > that is what makes open source software so great :)
> >
> > Same here, even if time available for OSS isn't as big as I would like
> > it to be :(
>
> :)
>
>


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


Mime
View raw message