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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
