You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jason Foster <ja...@uwaterloo.ca> on 2001/10/05 04:32:59 UTC
RT - Tree Traversal Implementation of Sitemaps and XSP
It may be a little pretentious to use the "RT" prefix, but this is a random
thought, so here goes...
During some of my (admittedly small amounts of) work with Cocoon I have
found myself having to deal with the generated source code for the sitemap
and some XSP pages. Needless to say this was not a terribly pleasant
experience.
It occurred to me that the path a request takes through the sitemap, or the
generation of content from an XSP page, can be seen as a slightly involved
tree traversal. In combination with the Strategy pattern from the GOF, I
got the following crazy idea:
Why not parse the sitemap and create an in-memory representation
(DOM,JDOM,???) where each node references both a component (Reader,
Transformer, etc.) and a traversal strategy. When a request comes in:
1. Create the appropriate object encapsulating the parameters, etc.
2. Request a thread from a request handling thread pool
3. Pass the thread the request object and the root of the sitemap tree
Traversal of the tree basically consists of:
1. Request the strategy for the current node
2. Ask the strategy to do its thing
2a. Which in most cases is likely to be a pre-order traversal, I think
For some reason the conceptual model of a bunch of request objects
traversing the sitemap tree seems a lot clearer than the current approach.
Is this a good idea? I really don't know. It does everything the current
approach does (I think), feels cleaner (to me) , and might make debugging
easier (ask the request to report on the path through the tree that it
took). Without trying I can't tell if it would be faster or slower, or what
the RAM consumption would be.
I am really curious as to why Cocoon has adopted the XSLT code generation
approach? It really seems to make debugging a pain, as well as placing a
dependency on having a java compiler on the runtime system. I haven't been
trying too hard to figure out what the advantages to this approach are, but
I haven't come up with any. I have no doubt that any interested readers
will enlighten me :)
Anyways, I don my asbestos underwear in preparation for your replies...
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Peter Royal <pr...@managingpartners.com>.
At 02:05 PM 10/6/2001 +0200, you wrote:
> > 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.
>
>Did you obtain any visible performance improvement?
I never got a chance to test performance. The main benefit when I made the
change was ease of debugging :)
I plan to move most of my code from XSP pages to transformers though.
Currently I'm inserting my dynamic data into my mostly-static pages very
early in the pipeline, thus undermining the excellent caching abilities of
cocoon.
>Oh, absolutely. Please, keep in mind that the new behavior that we are
>discussing about tree traversal (thus sitemap interpretation vs.
>compilation) will be *TOTALLY* back compatible and will not change the
>sitemap semantics.
>
>Sorry, I thought this was obvious.
I figured it would be compatible in the near term, but with some of the
more radical ideas I've seen proposed (flowmap), I thought that down the
road we would eventually hit a wall that the sitemap can't scale :)
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Gianugo Rabellino <gi...@rabellino.it>.
Boy, I wish I had some time to jump in the great topics that are being
discussed on the list lately. I hope to come up with some points in the
next week: meanwhile I'd just like to clarify a side point:
> > 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.
Sylvain, first of all thanks a lot for the plug. :) I just wanted to
point out that X:Forge is not at all based on introspection. It's a pure
component based approach where, of course, you are free to use
introspection if you want to do so in your components, but the framework
is based on pure Avalon concepts.
I consider X:Forge a good attempt at component based dynamic XML
generation yet I admit that the approach (and the implementation) can be
improved a lot. Unfortunately Bibop reconsidered its position and
strategy lately, with many good programmers being laid off, so I
wouldn't expect any follow up on this particular product (but yes, there
will be good news on the dynamic XML generation field sooner or later,
I'm not going to give up... :)).
As of now, though, X:Forge it's there, it works and, in our tests, it
outperformed XSP many time, even by an order of magnitude for things
such as request/session analysis and complex DB queries. But most of all
(and don't ask me why) it seems to scale much better under load (keep in
mind though that our tests, at the time the software was written, were
run against Cocoon 1, even if X:Forge is totally based on SAX).
This is just a "real life" example in favor of components versus code
generation. :)
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by giacomo <gi...@apache.org>.
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
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
> <st...@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
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by giacomo <gi...@apache.org>.
On Thu, 25 Oct 2001, Sylvain Wallez wrote:
>
>
> giacomo a écrit :
> >
> > On Fri, 5 Oct 2001, 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.
> >
> > I'm not so enthusiastic about rewriting the sitemap engine from
> > compiled to interpreted. Rather a new approach for the hole
> > URIspace-/Flow-/resource-definition should be taken (as Berin proposed).
>
> 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.
> 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.
> 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).
> 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.
> 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 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?
No, I definitively don't like the co-existance of two semantically the
same achitecture implemented with different technologies into the same
system.
Giacomo
> Sylvain.
>
> > > 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 !
> > >
> > > 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.
> >
> > Yes, even for XSP I think new approaches will be better than rewrites.
> > You know, code-to-java production was very popular those days but as
> > with Cocoon 1.x vs. Cocoon 2.x (or better DOM vs. SAX) practice let you
> > learn new lessons.
> >
> > 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 :(
> > >
> > > Sylvain
> > >
> > > > keep hacking.
> > > > -pete
> > > >
> > > > --
> > > > peter royal -> proyal@managingpartners.com
> > > > managing partners, inc. -> http://www.managingpartners.com
> > > >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo a écrit :
>
> On Fri, 5 Oct 2001, 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.
>
> I'm not so enthusiastic about rewriting the sitemap engine from
> compiled to interpreted. Rather a new approach for the hole
> URIspace-/Flow-/resource-definition should be taken (as Berin proposed).
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.
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).
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. 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.
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.
Sylvain.
> > 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 !
> >
> > 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.
>
> Yes, even for XSP I think new approaches will be better than rewrites.
> You know, code-to-java production was very popular those days but as
> with Cocoon 1.x vs. Cocoon 2.x (or better DOM vs. SAX) practice let you
> learn new lessons.
>
> 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 :(
> >
> > Sylvain
> >
> > > keep hacking.
> > > -pete
> > >
> > > --
> > > peter royal -> proyal@managingpartners.com
> > > managing partners, inc. -> http://www.managingpartners.com
> > >
--
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
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by giacomo <gi...@apache.org>.
On Fri, 5 Oct 2001, 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.
I'm not so enthusiastic about rewriting the sitemap engine from
compiled to interpreted. Rather a new approach for the hole
URIspace-/Flow-/resource-definition should be taken (as Berin proposed).
> 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 !
>
> 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.
Yes, even for XSP I think new approaches will be better than rewrites.
You know, code-to-java production was very popular those days but as
with Cocoon 1.x vs. Cocoon 2.x (or better DOM vs. SAX) practice let you
learn new lessons.
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 :(
>
> Sylvain
>
> > keep hacking.
> > -pete
> >
> > --
> > peter royal -> proyal@managingpartners.com
> > managing partners, inc. -> http://www.managingpartners.com
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Royal wrote:
>
> At 02:24 PM 10/6/2001 +0200, you wrote:
> >Also, I've never seen a case where the need for dynamically generated
> >pipelines could not be solved with more carefully designed static
> >pipelines.
> >
> >However, if you have any example that proves me wrong, I'll be happy to
> >reconsider my position.
>
> Here's my example, if it doesn't prove you wrong, I'd love to know how else
> I could implement it :)
Hopefully this helps a bit.
> The dynamically generated piece of pipeline that I'm using is for i18n
> transformation.
Ok.
> We are using cocoon as the basis for our web-based
> application, and each data-entry form is represented by an XSP file. We
> also have an object-model in the back end to describe the business systems.
> Each XSP form gives an entry point to edit the object model at a specific
> point. So each form could operate on an object, its parents, some of its
> children, and maybe some FK-type relatives.
>
> The translation steps that we go through are:
> generate i18n elements ->
> form-specific translations ->
> regenerate i18n ->
> primary object translations ->
> (repeat for each linked child/parent/etc: generate i18n elements -> linked
> object translations) ->
> regenerate i18n for any non-translated items ->
> default-catch all translations (common terms like address, phone#, etc).
>
> This lets us override translations for any more specific use of an
> object. Say you have a Customer that has Locations. On a Location edit
> screen the "description" attribute of the Location may be translated as
> "Description". But if you are on a Customer screen that has a Foreign-Key
> link to a primary location, you may want to translate the "description"
> attribute of that location as "Primary Location Description".
>
> The pipeline to display a form to a user has no concept as to which objects
> it is operating on. It is very simple:
> Generate->Translate->Serialize.
Ok, think about it: you are not doing anything really dynamic since you
can describe the above pipeline without requiring any conditional (if
this do that, etc..).
The pipeline you describe is, therefore, static, not meaning that the
content it generates doesn't change with time, but that its behavior,
the way the resource are generated don't change with time.
> Currently I am the one that created the
> dynamic pipeline and maintains the sitemap, so I don't have an SoC concern.
> The user that creates forms doesn't mess with the sitemap at all.
Ok, but my concerns still remain: if one of your pipeline component must
react on some parameter to change its behavior, is not by changing the
sitemap to allow dynamic use of an existing component, my proposed
strategy would be to extend an existing component and make it more
dynamic, rather than modifying the way the pipelines are composed in
order to obtain the same effect.
> I don't want to have to make a bunch of different pipelines, and while I
> could fold my translations into a single transformer
You said it: I could fold my translations into a single transformer: you
are a java programmer right? why don't you write your own transformer
that implements the behavior you want?
I hear you saying: but with the sitemap would be easier. It might be,
but this is not a good reason to start adding semantics to the sitemap
that would easily turn it into a procedural language.
It's the same issue with Ant build files: tasks should contain dynamic
logic and bahavior should be fixed in component composition.
It's also the same as inlike dynamic code regeneration, a trick that
assembly coders use to optimize their code by readapting dynamically the
code by rewriting the memory cell right before the processor executes
it.
Almost everybody today knows this is shooting yourself in the foot big
time.
, I saved time by just
> using the existing i18n transformer and some XSLT stylesheets. Since this
> is a somewhat intensive operation, this is why I am going to move away from
> generating the data for the form in the generate step, to inserting it
> after the translation has taken place. That way the translated forms could
> be cached.
>
> I guess what it comes down to is that the SoC argument changes depending on
> what the creation is. For those of us that are developing applications with
> Cocoon, we might not want to separate concerns as much :)
Well, you should anyway: it allows parallel work not only from different
people, but also organizes better the work that one person should do. In
short, one mistake you make in one concern area don't reflect in the
other as much as the contracts are not changed.
In short, crosscutting concerns is a way to work twice when you could
work once.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Peter Royal <pr...@managingpartners.com>.
At 02:24 PM 10/6/2001 +0200, you wrote:
>Also, I've never seen a case where the need for dynamically generated
>pipelines could not be solved with more carefully designed static
>pipelines.
>
>However, if you have any example that proves me wrong, I'll be happy to
>reconsider my position.
Here's my example, if it doesn't prove you wrong, I'd love to know how else
I could implement it :)
The dynamically generated piece of pipeline that I'm using is for i18n
transformation. We are using cocoon as the basis for our web-based
application, and each data-entry form is represented by an XSP file. We
also have an object-model in the back end to describe the business systems.
Each XSP form gives an entry point to edit the object model at a specific
point. So each form could operate on an object, its parents, some of its
children, and maybe some FK-type relatives.
The translation steps that we go through are:
generate i18n elements ->
form-specific translations ->
regenerate i18n ->
primary object translations ->
(repeat for each linked child/parent/etc: generate i18n elements -> linked
object translations) ->
regenerate i18n for any non-translated items ->
default-catch all translations (common terms like address, phone#, etc).
This lets us override translations for any more specific use of an
object. Say you have a Customer that has Locations. On a Location edit
screen the "description" attribute of the Location may be translated as
"Description". But if you are on a Customer screen that has a Foreign-Key
link to a primary location, you may want to translate the "description"
attribute of that location as "Primary Location Description".
The pipeline to display a form to a user has no concept as to which objects
it is operating on. It is very simple:
Generate->Translate->Serialize. Currently I am the one that created the
dynamic pipeline and maintains the sitemap, so I don't have an SoC concern.
The user that creates forms doesn't mess with the sitemap at all.
I don't want to have to make a bunch of different pipelines, and while I
could fold my translations into a single transformer, I saved time by just
using the existing i18n transformer and some XSLT stylesheets. Since this
is a somewhat intensive operation, this is why I am going to move away from
generating the data for the form in the generate step, to inserting it
after the translation has taken place. That way the translated forms could
be cached.
I guess what it comes down to is that the SoC argument changes depending on
what the creation is. For those of us that are developing applications with
Cocoon, we might not want to separate concerns as much :)
I hope I've explained myself well.
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Royal wrote:
> One new feature i'd love to see is the construction of dynamic pipelines. I
> have a hack for this in my own code right now as a transformer which
> creates its own mini-pipeline inside of itself.
Even if runtime sitemap tree travesal will make easier to implement
this, I keep on being against such an approach even if I had the
temptation myself to use something equivalent.
The reason: it breaks separation of concerns because the sitemap
administrator and the programmers that generates the code that generates
the dynamic pipeline must be the same person or must overlap completely.
Also, I've never seen a case where the need for dynamically generated
pipelines could not be solved with more carefully designed static
pipelines.
However, if you have any example that proves me wrong, I'll be happy to
reconsider my position.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Peter Royal <pr...@managingpartners.com>.
At 04:23 PM 10/5/2001 +0200, you wrote:
>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 followed those threads also, and i think with the number of different
approaches available, it would be possible to move away from XSP. I think I
could replace our major use of it here with the file generator and then
some transformers. I've recently started hacking away at transformers more.
Previous uses were more XSLT sheets. The power there is immense! I can
definitely see the direction that berin and stefano are thinking in.
One new feature i'd love to see is the construction of dynamic pipelines. I
have a hack for this in my own code right now as a transformer which
creates its own mini-pipeline inside of itself.
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
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 !
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 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 :(
Sylvain
> keep hacking.
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
> managing partners, inc. -> http://www.managingpartners.com
>
--
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
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> > 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.
>
> Oh, absolutely. Please, keep in mind that the new behavior that we are
> discussing about tree traversal (thus sitemap interpretation vs.
> compilation) will be *TOTALLY* back compatible and will not change the
> sitemap semantics.
>
> Sorry, I thought this was obvious.
The REAL trick is to get the "CodeFactory" selectors/matchers to work in an
interpretted environment. We may have to remove the notion of "CodeFactory"
and use real components for Selectors/Matchers. Hopefully this can be done
without breaking sitemap markup (I think it can).
This really needs to be done sooner than later.
> > 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 :)
>
> Yes. Sometimes is frustrating for those who do the unsexy work and would
> rather join but don't have time, but it's the only drawback of such an
> open development and it allows everybody to influence the design making
> it a real product for the people and by the people. (no political pun
> intended, just happened to be a quote from a famous US president).
It's actually a quote from the Preamble to the Consitution of the US. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] architecture design
Posted by Gianugo Rabellino <gi...@rabellino.it>.
> >Halfway there, hope to have a working version by the end of this
week...
> >:)
> >
> How difficult is it to write such a new protocol ? I am currently
> working on integrating Cocoon 2 with Documentum, and we are planning
to
> add a "docbase" protocol for accessing XML documents directly from
> Documentum repository servers.
Not much. A good starting point is the SourceFactory interface, AFAIK
basically you have to implement your own Source, make it available via a
SourceFactory declared in cocoon.xconf, and you're ready to roll.
Beware: SourceHandlerImpl was not Configurable until a while ago, and I
don't know if Carsten committed my patch other than to the HEAD version:
if you need to pass a Configuration object make sure to use the updated
SourceHandlerImpl.
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [STATUS] architecture design
Posted by Michael Hartle <mh...@hartle-klug.com>.
Matthew Langham wrote:
>Hi Michael (and team),
>
>How difficult is it to write such a new protocol ? I am currently
>working on integrating Cocoon 2 with Documentum, and we are planning to
>add a "docbase" protocol for accessing XML documents directly from
>Documentum repository servers.
><<
>
>Documentum sounds very interesting. Is this something you are planning on
>committing to Cocoon? We have been doing quite a bit of work connecting our
>Cocoon based solution to Software AGs Tamino database. We are currently
>considering rewriting what we have done as a protocol.
>
Today, I got the confirmation that I am being fully supported a customer
of ours in developing a Docbase protocol extension for Cocoon. As they
gain a step forward towards integrating Documentum and Cocoon for free
in return, I am free, willing and planing to commit the extension as
soon as the work is completed.
>So, is the addition of new protocols such as Documentum, Tamino etc.
>something the Cocoon community in general would be interested in?
>
I really think so; at least I am definitely interested in a Tamino
protocol extension to Cocoon... ;)
Proving that Cocoon can support complex software products such as
Documentum and Tamino is just another advantage that counts in favour of
using open source projects like Cocoon.
>Matthew
>
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [STATUS] architecture design
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Matthew Langham wrote:
>
> Hi Michael (and team),
>
> >>
> >>>Ok, you guys add more comments if you need to.
> >>>
> >>There is still some thought in my mind about dbXML (or other XML
> >>DBs) which could result in a new protocol for a Source of XML.
> >>
> >Halfway there, hope to have a working version by the end of this week...
> >:)
> >
> How difficult is it to write such a new protocol ? I am currently
> working on integrating Cocoon 2 with Documentum, and we are planning to
> add a "docbase" protocol for accessing XML documents directly from
> Documentum repository servers.
> <<
>
> Documentum sounds very interesting. Is this something you are planning on
> committing to Cocoon? We have been doing quite a bit of work
> connecting our
> Cocoon based solution to Software AGs Tamino database. We are currently
> considering rewriting what we have done as a protocol.
>
> So, is the addition of new protocols such as Documentum, Tamino etc.
> something the Cocoon community in general would be interested in?
>
Absolutely!
+1 for documentum
+1 for tamino
Carsten
> Matthew
>
> --
> Open Source Group sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
> =================================================================
>
>
> -----Ursprungliche Nachricht-----
> Von: Michael Hartle [mailto:mhartle@hartle-klug.com]
> Gesendet: Montag, 29. Oktober 2001 23:44
> An: cocoon-dev@xml.apache.org
> Betreff: Re: [STATUS] architecture design
>
>
> Gianugo Rabellino wrote:
>
> >>>Ok, you guys add more comments if you need to.
> >>>
> >>There is still some thought in my mind about dbXML (or other XML
> >>DBs) which could result in a new protocol for a Source of XML.
> >>
> >Halfway there, hope to have a working version by the end of this week...
> >:)
> >
> How difficult is it to write such a new protocol ? I am currently
> working on integrating Cocoon 2 with Documentum, and we are planning to
> add a "docbase" protocol for accessing XML documents directly from
> Documentum repository servers.
>
> Best regards,
>
> Michael Hartle
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [STATUS] architecture design
Posted by Matthew Langham <ml...@s-und-n.de>.
Hi Michael (and team),
>>
>>>Ok, you guys add more comments if you need to.
>>>
>>There is still some thought in my mind about dbXML (or other XML
>>DBs) which could result in a new protocol for a Source of XML.
>>
>Halfway there, hope to have a working version by the end of this week...
>:)
>
How difficult is it to write such a new protocol ? I am currently
working on integrating Cocoon 2 with Documentum, and we are planning to
add a "docbase" protocol for accessing XML documents directly from
Documentum repository servers.
<<
Documentum sounds very interesting. Is this something you are planning on
committing to Cocoon? We have been doing quite a bit of work connecting our
Cocoon based solution to Software AGs Tamino database. We are currently
considering rewriting what we have done as a protocol.
So, is the addition of new protocols such as Documentum, Tamino etc.
something the Cocoon community in general would be interested in?
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Michael Hartle [mailto:mhartle@hartle-klug.com]
Gesendet: Montag, 29. Oktober 2001 23:44
An: cocoon-dev@xml.apache.org
Betreff: Re: [STATUS] architecture design
Gianugo Rabellino wrote:
>>>Ok, you guys add more comments if you need to.
>>>
>>There is still some thought in my mind about dbXML (or other XML
>>DBs) which could result in a new protocol for a Source of XML.
>>
>Halfway there, hope to have a working version by the end of this week...
>:)
>
How difficult is it to write such a new protocol ? I am currently
working on integrating Cocoon 2 with Documentum, and we are planning to
add a "docbase" protocol for accessing XML documents directly from
Documentum repository servers.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] architecture design
Posted by Michael Hartle <mh...@hartle-klug.com>.
Gianugo Rabellino wrote:
>>>Ok, you guys add more comments if you need to.
>>>
>>There is still some thought in my mind about dbXML (or other XML
>>DBs) which could result in a new protocol for a Source of XML.
>>
>Halfway there, hope to have a working version by the end of this week...
>:)
>
How difficult is it to write such a new protocol ? I am currently
working on integrating Cocoon 2 with Documentum, and we are planning to
add a "docbase" protocol for accessing XML documents directly from
Documentum repository servers.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] architecture design
Posted by giacomo <gi...@apache.org>.
On Mon, 29 Oct 2001, Gianugo Rabellino wrote:
> > > Ok, you guys add more comments if you need to.
> >
> > There is still some thought in my mind about dbXML (or other XML
> > DBs) which could result in a new protocol for a Source of XML.
>
> Halfway there, hope to have a working version by the end of this week...
> :)
Oh, cool :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] architecture design
Posted by Gianugo Rabellino <gi...@rabellino.it>.
> > Ok, you guys add more comments if you need to.
>
> There is still some thought in my mind about dbXML (or other XML
> DBs) which could result in a new protocol for a Source of XML.
Halfway there, hope to have a working version by the end of this week...
:)
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] architecture design
Posted by giacomo <gi...@apache.org>.
On Sun, 28 Oct 2001, Stefano Mazzocchi wrote:
> 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.
This is IMHO the main problem
> 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.
Agreed.
> c) the use of code generation and compilation increases load time and is
> believed not to increase runtime performance due to hotspot removal.
There are other reasons for eliminating code generation and compilation
like complexity which the javac imposes, or easier reloading strategies.
> d) mostly due to c) and further implementation details, sitemaps cannot
> be cleanly nested and components inherited.
Well, this is due to the existance of the CodeFactory interface which
IIRC is eliminated in the HEAD branch.
> 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.
+1 This doesn't mean that I've changed my mind in regards of rewriting
the current sitemap semantics from a currently compiled into a
interpreted one. Sure, I wouldn't stop any volunteer doing so but my
vote on this will be -0.
> 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.
I don't prefer either one. The proposal from Berin is IMHO a new
approach and will have another learning curve than the on from Daniela,
which I've grasp immediately (more or less :)
> 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).
+1
> 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.
There is still some thought in my mind about dbXML (or other XML
DBs) which could result in a new protocol for a Source of XML.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[STATUS] architecture design
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by giacomo <gi...@apache.org>.
On Sat, 6 Oct 2001, Stefano Mazzocchi wrote:
> Peter Royal wrote:
> >
> > 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?
>
> Probably so.
>
> > 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.
>
> Did you obtain any visible performance improvement?
>
> > I mention this because maybe we could apply some of the same techniques to
> > the sitemap?
>
> Well, we sorta do that already. The sitemap is more or less composed by
> a bunch of if/then/else considitional constructs that implement the tree
> traversal hardwired.
>
> > 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?
>
> Maybe we could do some more, but I think the sitemap stylesheet is
> already close to the very bone of the code that needs to be
> automatically created. Anyway, if you have specific suggestions based on
> the sitemap code, I'm more than willing to hear them and consider them.
>
> > That might provide a migration plan towards a more radical design.
>
> Well, the sitemap is the contract and as long as it doesn't change, you
> shouldn't care if it gets compiled or interpreted or whatever else.
>
> > 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.
>
> Oh, absolutely. Please, keep in mind that the new behavior that we are
> discussing about tree traversal (thus sitemap interpretation vs.
> compilation) will be *TOTALLY* back compatible and will not change the
> sitemap semantics.
>
> Sorry, I thought this was obvious.
No it is not. We have seen that the sitemap covers too many concerns and
making it compiled or interpreted dosn't change it. Thus my proposal to
leave it as it is and lets open new ideas (as Berin ones) to
better separate the concerns.
> > 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 :)
>
> Yes. Sometimes is frustrating for those who do the unsexy work and would
> rather join but don't have time, but it's the only drawback of such an
> open development and it allows everybody to influence the design making
> it a real product for the people and by the people. (no political pun
> intended, just happened to be a quote from a famous US president).
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 ;)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Royal wrote:
>
> 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?
Probably so.
> 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.
Did you obtain any visible performance improvement?
> I mention this because maybe we could apply some of the same techniques to
> the sitemap?
Well, we sorta do that already. The sitemap is more or less composed by
a bunch of if/then/else considitional constructs that implement the tree
traversal hardwired.
> 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?
Maybe we could do some more, but I think the sitemap stylesheet is
already close to the very bone of the code that needs to be
automatically created. Anyway, if you have specific suggestions based on
the sitemap code, I'm more than willing to hear them and consider them.
> That might provide a migration plan towards a more radical design.
Well, the sitemap is the contract and as long as it doesn't change, you
shouldn't care if it gets compiled or interpreted or whatever else.
> 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.
Oh, absolutely. Please, keep in mind that the new behavior that we are
discussing about tree traversal (thus sitemap interpretation vs.
compilation) will be *TOTALLY* back compatible and will not change the
sitemap semantics.
Sorry, I thought this was obvious.
> 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 :)
Yes. Sometimes is frustrating for those who do the unsexy work and would
rather join but don't have time, but it's the only drawback of such an
open development and it allows everybody to influence the design making
it a real product for the people and by the people. (no political pun
intended, just happened to be a quote from a famous US president).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by giacomo <gi...@apache.org>.
On Fri, 5 Oct 2001, Peter Royal wrote:
> 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.
This is a serious issue. As Berin also mentioned an approach having the
"sitemap" engines pluggable to preserve version 2.0 sitemaps and being
able to implement the next generation engine. Then people are free to
use whichever they need. Sure, this approach has the brawback that the
old sitemap engine isn't maintained and will die sooner or later.
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 :)
>
> keep hacking.
> -pete
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Peter Royal <pr...@managingpartners.com>.
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.
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 :)
keep hacking.
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Berin Loritsch <bl...@apache.org>.
Sergio Carvalho wrote:
>
> On Fri, 05 Oct 2001 09:52:45 -0400, Berin Loritsch wrote:
> From: Berin Loritsch <bl...@apache.org>
> --
>
> >
> > Home > Projects > Cocoon > Installation
> >
> > I have been trying to come up with a good way for Cocoon to automatically
> create
> > this, and haven't come up with anything elegant. Tree traversal would be a
> > perfect match.
>
> Since this is a major site usability feature (see: useit.com), it should be
> provided by core cocoon. Note that this should exist in most sites, not just
> directories.
>
> I currently do it with a SectionCutter action, which divides my site into
> separate hierarchic sections, and then XSLT transform those to produce both the
> advertisement html snippet, and the navigation bar. I'd be happy to donate the
> SectionCutter, although you're probably looking for something more elaborate.
Actually, this might be enough. If you could commit the SectionCutter action,
it would help developing sites to use it. I know it will help with navigating
the docs in Avalon and Cocoon.
> > As it is currently implemented, the Sitemap gets the implementor thinking
> > linearly instead of spacially. In other words the view of the Sitemap
> > administrator is a straight line of if/then/else statements as opposed
> > to a two dimensional map of URI space and resources.
>
> Very very cool. From my experience, 20% of the pipelines perform 80% of the
> requests, so complete pipeline pooling can definitely introduce performance
> enhancements. I also vouch for avoiding code generation where possible. It's a
> real pain to debug.
Amen to that!
> I must confess I managed to miss the RTs where FlowMaps and URIMaps were
> discussed. I'm glad to see the refactoring of the sitemap concept under
> discussion. I'd like to see the sitemap be just a URI to visual component
> mapper. That would mean having the sitemap just define the aggregations which
> compose each page. It would be great from a content management perspective.
Exactly. The FlowMap and URIMap approaches merely simplified the Sitemap
into different concern areas. For instance, the FlowMap is vital for form
validation and application specific logic. The URIMap is more an administrator's
concern who decides where to mount different flows or other visual resources.
> The visual components would have to be defined elsewhere, and preferrably,
> should be drop-in deployable (e.g.: jar copying). This is because most site
> components (menus, news articles, navbars, banners) could be off-the-shelf
> components, and only some data-processing pages need to be custom made.
Exactly. That's what the other thread is attempting to address.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
Sergio Carvalho wrote:
>
> On Fri, 05 Oct 2001 09:52:45 -0400, Berin Loritsch wrote:
> From: Berin Loritsch <bl...@apache.org>
> --
>
> >
> > Home > Projects > Cocoon > Installation
> >
> > I have been trying to come up with a good way for Cocoon to automatically
> create
> > this, and haven't come up with anything elegant. Tree traversal would be a
> > perfect match.
>
> Since this is a major site usability feature (see: useit.com), it should be
> provided by core cocoon. Note that this should exist in most sites, not just
> directories.
>
> I currently do it with a SectionCutter action, which divides my site into
> separate hierarchic sections, and then XSLT transform those to produce both the
> advertisement html snippet, and the navigation bar. I'd be happy to donate the
> SectionCutter, although you're probably looking for something more elaborate.
I have implemented a general component for pagination and for path
expansion as part of my image gallery effort that I'll donate as soon as
it's finished (should be real soon now).
> > It very well might be quicker. I have an idea that is not tree traversal,
> > but it would work equally well. The short description is this:
> >
> > All pipelines are pre-configured and treated as proper components. As a
> > URI request comes in, it is fed to the Sitemap Pipeline Selector. This
> > approach takes advantage of pooling, and as specific pipelines are used,
> > the pool keeps enough in memory. Thus, the pipelines that are used less
> > often don't have as many instances.
> >
> > In the end, the structure of a pipeline is configurable--encapsulating
> > sub-sitemaps and all the other logic. With the pipeline centric approach,
> > the lookup is done via a HashMap scheme which has proven to be efficient
> > during runtime. The maximum number of lookups is directly related to
> > the number of sub sitemaps.
> >
> > This proposal combined with Cocoon Apps (with the URIMap, FlowMap, and
> > named Cocoon components) would be very effective. The shift in focus
> > of the URIMap vs. the Sitemap automatically gets you thinking what will
> > be the least amount of work to achieve the desired URI space. The URI
> > space will be immediately known--and 404 errors can be even more quickly
> > returned.
> >
> > As it is currently implemented, the Sitemap gets the implementor thinking
> > linearly instead of spacially. In other words the view of the Sitemap
> > administrator is a straight line of if/then/else statements as opposed
> > to a two dimensional map of URI space and resources.
>
> Very very cool. From my experience, 20% of the pipelines perform 80% of the
> requests, so complete pipeline pooling can definitely introduce performance
> enhancements. I also vouch for avoiding code generation where possible. It's a
> real pain to debug.
I think we all agree on that.
> I must confess I managed to miss the RTs where FlowMaps and URIMaps were
> discussed. I'm glad to see the refactoring of the sitemap concept under
> discussion. I'd like to see the sitemap be just a URI to visual component
> mapper. That would mean having the sitemap just define the aggregations which
> compose each page. It would be great from a content management perspective.
> The visual components would have to be defined elsewhere, and preferrably,
> should be drop-in deployable (e.g.: jar copying). This is because most site
> components (menus, news articles, navbars, banners) could be off-the-shelf
> components, and only some data-processing pages need to be custom made.
I definately agree on making cocoon web application more componentizable
but I thing it's going to be hard to get that granular.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Sergio Carvalho <se...@acm.org>.
On Fri, 05 Oct 2001 09:52:45 -0400, Berin Loritsch wrote:
From: Berin Loritsch <bl...@apache.org>
--
>
> Home > Projects > Cocoon > Installation
>
> I have been trying to come up with a good way for Cocoon to automatically
create
> this, and haven't come up with anything elegant. Tree traversal would be a
> perfect match.
Since this is a major site usability feature (see: useit.com), it should be
provided by core cocoon. Note that this should exist in most sites, not just
directories.
I currently do it with a SectionCutter action, which divides my site into
separate hierarchic sections, and then XSLT transform those to produce both the
advertisement html snippet, and the navigation bar. I'd be happy to donate the
SectionCutter, although you're probably looking for something more elaborate.
> It very well might be quicker. I have an idea that is not tree traversal,
> but it would work equally well. The short description is this:
>
> All pipelines are pre-configured and treated as proper components. As a
> URI request comes in, it is fed to the Sitemap Pipeline Selector. This
> approach takes advantage of pooling, and as specific pipelines are used,
> the pool keeps enough in memory. Thus, the pipelines that are used less
> often don't have as many instances.
>
> In the end, the structure of a pipeline is configurable--encapsulating
> sub-sitemaps and all the other logic. With the pipeline centric approach,
> the lookup is done via a HashMap scheme which has proven to be efficient
> during runtime. The maximum number of lookups is directly related to
> the number of sub sitemaps.
>
> This proposal combined with Cocoon Apps (with the URIMap, FlowMap, and
> named Cocoon components) would be very effective. The shift in focus
> of the URIMap vs. the Sitemap automatically gets you thinking what will
> be the least amount of work to achieve the desired URI space. The URI
> space will be immediately known--and 404 errors can be even more quickly
> returned.
>
> As it is currently implemented, the Sitemap gets the implementor thinking
> linearly instead of spacially. In other words the view of the Sitemap
> administrator is a straight line of if/then/else statements as opposed
> to a two dimensional map of URI space and resources.
Very very cool. From my experience, 20% of the pipelines perform 80% of the
requests, so complete pipeline pooling can definitely introduce performance
enhancements. I also vouch for avoiding code generation where possible. It's a
real pain to debug.
I must confess I managed to miss the RTs where FlowMaps and URIMaps were
discussed. I'm glad to see the refactoring of the sitemap concept under
discussion. I'd like to see the sitemap be just a URI to visual component
mapper. That would mean having the sitemap just define the aggregations which
compose each page. It would be great from a content management perspective.
The visual components would have to be defined elsewhere, and preferrably,
should be drop-in deployable (e.g.: jar copying). This is because most site
components (menus, news articles, navbars, banners) could be off-the-shelf
components, and only some data-processing pages need to be custom made.
--
Sergio Carvalho
---------------
sergio.carvalho@acm.org
If at first you don't succeed, skydiving is not for you
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> > In combination with the Strategy pattern from the GOF, I
> > got the following crazy idea:
> >
> > Why not parse the sitemap and create an in-memory representation
> > (DOM,JDOM,???) where each node references both a component (Reader,
> > Transformer, etc.) and a traversal strategy. When a request comes in:
> >
> > 1. Create the appropriate object encapsulating the parameters, etc.
> > 2. Request a thread from a request handling thread pool
> > 3. Pass the thread the request object and the root of the sitemap tree
> >
> > Traversal of the tree basically consists of:
> >
> > 1. Request the strategy for the current node
> > 2. Ask the strategy to do its thing
> > 2a. Which in most cases is likely to be a pre-order traversal, I think
> >
> > For some reason the conceptual model of a bunch of request objects
> > traversing the sitemap tree seems a lot clearer than the current approach.
>
> Oh, most definately.
It also allows for an easier way to implement heirarchy lists. You know how
on some sites (like directory sites) you have a string of links accross the
top looking like this:
Home > Projects > Cocoon > Installation
I have been trying to come up with a good way for Cocoon to automatically create
this, and haven't come up with anything elegant. Tree traversal would be a
perfect match.
> > Is this a good idea? I really don't know.
>
> I'll tell you one thing: don't know if you had the patience to read thru
> all the recent RT between Berin and I, but we both indicated that the
> current technique to compile the sitemap is slow, hard to understand and
> very impractical at least for Cocoon development.
>
> The only place were sitemap compilation might have a place is for
> binary-only cocoon webapps that need to be deployed in production, but
> this is yet to be seen.
I think there are a couple live C2 apps. If the sitemap doesn't change, or
get touched, the compiled class is used. It is not an explicit contract,
but it does happen.
> > It does everything the current
> > approach does (I think), feels cleaner (to me) , and might make debugging
> > easier (ask the request to report on the path through the tree that it
> > took). Without trying I can't tell if it would be faster or slower, or what
> > the RAM consumption would be.
>
> For sure, the memory consumption would be worse for production
> enviornments where sitemaps never change and better for development
> environments where sitemaps continously change.
Servers usually have copious amounts of RAM... ;)
Seriously, several projects (like Squid proxy server) use a compiled BTREE
implementation during run time. It assembles the BTREE in RAM, and serializes
it to the disk so it can read it directly back in later. BTREEs are supposed
to be one of the fastest run-time approaches for tree traversals but do it
at the price of extensive use of RAM.
> In theory, (if we are lucky) we might find out that such a code might
> even be faster than if written directly in native code: in fact, such a
> continous and dynamically adapting JIT polishing of the native code,
> might turn out to perform real-time optimization that adapt on the type
> of load, something that would be much harder to do if we were to rewrite
> Cocoon in native code to make it faster.
It very well might be quicker. I have an idea that is not tree traversal,
but it would work equally well. The short description is this:
All pipelines are pre-configured and treated as proper components. As a
URI request comes in, it is fed to the Sitemap Pipeline Selector. This
approach takes advantage of pooling, and as specific pipelines are used,
the pool keeps enough in memory. Thus, the pipelines that are used less
often don't have as many instances.
In the end, the structure of a pipeline is configurable--encapsulating
sub-sitemaps and all the other logic. With the pipeline centric approach,
the lookup is done via a HashMap scheme which has proven to be efficient
during runtime. The maximum number of lookups is directly related to
the number of sub sitemaps.
This proposal combined with Cocoon Apps (with the URIMap, FlowMap, and
named Cocoon components) would be very effective. The shift in focus
of the URIMap vs. the Sitemap automatically gets you thinking what will
be the least amount of work to achieve the desired URI space. The URI
space will be immediately known--and 404 errors can be even more quickly
returned.
As it is currently implemented, the Sitemap gets the implementor thinking
linearly instead of spacially. In other words the view of the Sitemap
administrator is a straight line of if/then/else statements as opposed
to a two dimensional map of URI space and resources.
> > It really seems to make debugging a pain, as well as placing a
> > dependency on having a java compiler on the runtime system.
>
> Absolutely, expecially given javac which is written only for command
> line and has no stream in/out capabilities and is not redistributable.
BCEL (recently proposed to join the apache fold) would take care of that.
For those of you who don't know what BCEL is, it is a byte code engineering
layer that you can implement your own parsers and have valid java byte code
come out.
It does not erase the issue of debugging, however. One thing that can
more easily be done with implementing your own parser is embedding locator
logic so that your exceptions report line numbers in the Sitemap and XSP
files.
> > I haven't been
> > trying too hard to figure out what the advantages to this approach are, but
> > I haven't come up with any.
>
> As I said (but I have no figures to prove this), I believe current
> approach is a winner for JDK 1.1 and 1.2, while is very likely to fail
> on all issues but memory consumption on JDK 1.3 and 1.4 (and very
> likely, all future versions)
We have already had some evidence of this. There are some serious resource/memory
leaks involved in dynamically compiled resources that Cocoon developers have
tried to work around. I don't see it getting any better real soon.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
Oh, man, I just love these threads :)
Jason Foster wrote:
>
> It may be a little pretentious to use the "RT" prefix, but this is a random
> thought, so here goes...
Hey, there is no such thing as "pretentious" here. even if I was the
first to use the term RT to indicate more abstract reasoning, I'm for
sure not the only one that does think that way.
> During some of my (admittedly small amounts of) work with Cocoon I have
> found myself having to deal with the generated source code for the sitemap
> and some XSP pages. Needless to say this was not a terribly pleasant
> experience.
Don't tell me.
> It occurred to me that the path a request takes through the sitemap, or the
> generation of content from an XSP page, can be seen as a slightly involved
> tree traversal.
I haven't really had the time to think about it, but I agree.
> In combination with the Strategy pattern from the GOF, I
> got the following crazy idea:
>
> Why not parse the sitemap and create an in-memory representation
> (DOM,JDOM,???) where each node references both a component (Reader,
> Transformer, etc.) and a traversal strategy. When a request comes in:
>
> 1. Create the appropriate object encapsulating the parameters, etc.
> 2. Request a thread from a request handling thread pool
> 3. Pass the thread the request object and the root of the sitemap tree
>
> Traversal of the tree basically consists of:
>
> 1. Request the strategy for the current node
> 2. Ask the strategy to do its thing
> 2a. Which in most cases is likely to be a pre-order traversal, I think
>
> For some reason the conceptual model of a bunch of request objects
> traversing the sitemap tree seems a lot clearer than the current approach.
Oh, most definately.
> Is this a good idea? I really don't know.
I'll tell you one thing: don't know if you had the patience to read thru
all the recent RT between Berin and I, but we both indicated that the
current technique to compile the sitemap is slow, hard to understand and
very impractical at least for Cocoon development.
The only place were sitemap compilation might have a place is for
binary-only cocoon webapps that need to be deployed in production, but
this is yet to be seen.
> It does everything the current
> approach does (I think), feels cleaner (to me) , and might make debugging
> easier (ask the request to report on the path through the tree that it
> took). Without trying I can't tell if it would be faster or slower, or what
> the RAM consumption would be.
For sure, the memory consumption would be worse for production
enviornments where sitemaps never change and better for development
environments where sitemaps continously change.
As far as speed goes, I've already submitted another RT that states that
using modern hotspot techniques, compilation might be just like good old
loop-unrolling optimization techniques that I used to do for game coding
on x86 assembly when I was younger: since the 386 was slow as hell on
loops, simply unroll the loop if you knew in advance the loop cycles and
avoid taking memory for he counter, increase the counter and test the
counter.
As processor technology evolved, unrolled loops forced level 1 cache to
fetch more frequently and RISC-ification techniques to fail to optimize
the hotspots since the hotspot was "diluted" in the unrolled loop.
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.
Today, as more modern JVMs are made available, we might find out that
unrolling the loop (compiling the sitemap) is slower than performing
repeatedly a simple and well packed algorithm (which will create an
hotspot and greatly optimized by JIT compilers, expecially on server
environments where the hotspot may lasts there for months untouched).
In theory, (if we are lucky) we might find out that such a code might
even be faster than if written directly in native code: in fact, such a
continous and dynamically adapting JIT polishing of the native code,
might turn out to perform real-time optimization that adapt on the type
of load, something that would be much harder to do if we were to rewrite
Cocoon in native code to make it faster.
In short, I welcome your proposal and suggest you to present the list a
more detailed plan that we can implement.
> I am really curious as to why Cocoon has adopted the XSLT code generation
> approach?
Yes, I bet. Well, here it is: I'm a lazy butt and you all know that.
Also, I hate coding: if somebody else does it, I'm happier. I love brain
work and I love to draw things on my whiteboard, but when I have to code
it, well, I do it just if necessary.
Last year, Giacomo and Ricardo were my guests for a weekend and we
discussed the sitemap in detail. Ricardo had already wrote the XSP
machinery that allowed code to be compiled, loaded, executed and
recompiled if changed. When looking for a solution to implement the
sitemap, we thought about applying the same design patterns applied to
the XSP (at that time, we were very excited about dynamic compilation
technology) and Giacomo ended up writing the stylesheets for the sitemap
code generator and a few other things.
In a matter of days, he had a sitemap implementation ready. We were
amazed, it worked, it was fast (actually lightspeed compared to Cocoon1)
and we were happy enough to avoid going deeper into the problem.
Until recently.
> It really seems to make debugging a pain, as well as placing a
> dependency on having a java compiler on the runtime system.
Absolutely, expecially given javac which is written only for command
line and has no stream in/out capabilities and is not redistributable.
> I haven't been
> trying too hard to figure out what the advantages to this approach are, but
> I haven't come up with any.
As I said (but I have no figures to prove this), I believe current
approach is a winner for JDK 1.1 and 1.2, while is very likely to fail
on all issues but memory consumption on JDK 1.3 and 1.4 (and very
likely, all future versions)
> I have no doubt that any interested readers will enlighten me :)
Hope I did.
> Anyways, I don my asbestos underwear in preparation for your replies...
Nah, flamewars on this list as are so rare you can even forget about
wearing it for years, like I did :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org