On Thu, 07 Feb 2002 09:46:58 -0500, Berin Loritsch <[EMAIL PROTECTED]> wrote:
> Vadim Gritsenko wrote: > > >>>Moreover, I'd love to be able to decide what to use (interpreted or > >>>compiled) from cocoon.xconf.... or, in case the treeprocessor ends > >>> > > up > > > >>>faster all the time, simply blast the compiled version and get rid > >>> > > of > > > >>>that stupid javac! > >>> > >>+1 > > I like the ability to choose the Sitemap in use. In reality this turns > out to be an object implementing the Processor interface (like Cocoon > itself). > > By keying off of that relationship, I should be able to replace the Sitemap > with my own proprietary version. I definitely agree here. Schecoon depends on the contracts and some classes defined in the compiled version of the sitemap. I noticed in the TreeProcessor implementation that some code seems to duplicate some of the support classes in the compiled sitemap. It would be good to refactor the TreeProcessor code so that it shares the code with the one in the compiled sitemap. > So I am +1 on having the sitemap implementation pluggable. This allows for > us to experiment with different mapping techniques/technologies--while > maintaining the original markup. > > This is a *good* thing. I would be +1 on making the pluggability part of > the next maintenance release. But, just like Vadim, -1 on making the default > interpretted just yet. I believe the interpreted sitemap is already pluggable; what is the vote for? As for making the interpreted sitemap the default, I'm +1 on making the interpreted sitemap the default one. I think this way we squash the bugs much more quickly. As Vadim pointed out though, I think we should make another subminor release, with all the bug fixes after 2.0.1, before releasing the new version with the interpreted sitemap in it. Since replacing the compiled sitemap with interpreted one is a major change, I propose to name the new release 2.1, instead of 2.0.2. This way we indicate the drastic change that occurred in the new release. > > -1, it's quite a radical change. Let's make maintenance release first > > with the compiled sitemap engine present, and than I'm +1 on removing it > > (we will have enough time to catch every bug in it). Than, it would be > > logical to move interpreted sitemap engine to the main trunk after this > > maintenance release. > > > > What's your opinion on letting out 2.0.2? > > +1 +1. > >>>that stupid javac! > >>> > > > > Do not forget: XSP requires it. Is there any other stable java compiler > > around (fileless)? > > There is absolutely no java compiler that does not require the filesystem. > It is a major bummer, but there is little we can do. Jikes is much faster > than javac, so I would encourage its use if the site needs to squeeze a > bit more speed out. I think it's time for us to choose or come up with a markup technology that doesn't require compilation. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
