cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Sat, 06 Oct 2001 12:16:59 GMT
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.

> 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
*everybody* agrees better solutions have emerged and all of them have
migrated to them.
 
> 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.

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

> > 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 :(

:)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message