cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [vote] move tree-processor in the main trunk
Date Thu, 07 Feb 2002 17:32:51 GMT
On Thu, 07 Feb 2002 09:46:58 -0500, Berin Loritsch <bloritsch@apache.org> 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 <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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


Mime
View raw message