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.
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.
> -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
>>>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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
