You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/02/07 12:42:39 UTC
[vote] move tree-processor in the main trunk
Ok,
sitemap code generation is getting slower every day and is likely to
become worse as we add more bugfixes and error generation.
Clearly, developping on cocoon with 20 seconds delays between changes is
a nightmare and would scare people away instantly.
Now that we have a functional interpreted sitemap engine, I suggest we
move this on the main trunk and keep improving on it from there.
Also, I would like to propose a name change: TreeProcessor isn't exactly
self-explanatory as a 'sitemap interpreter'.
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!
What do you think?
--
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: [vote] move tree-processor in the main trunk
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jason Foster wrote:
> <snip/>
>
>> Just to make things clear : sitemap is only one of the possible uses
>> of the TreeProcessor : it's a generic framework for implementing
>> pipeline assembly languages (hence "Processor") with an evaluation
>> tree (hence "Tree").
>>
>> The supported languages are defined in treeprocessor.xconf or
>> cocoon.xconf, and the interpreted sitemap is "only" a particular
>> pipeline assembly language implemented using this framework, but we
>> could implement others like Berin's proposal or Daniela Gehle's
>> flowmap (go back to october 2001 in the archives to find them).
>
>
> Does that mean that XSPs that do not use compiled code fragments (Go
> Python! Go JavaScript! Go JavaBean! Down with Java source code!) can
> be handled by the TreeProcessor?
Read carefully : "...a generic framework for implementing *pipeline
assembly languages*...". XSP is a generator language and cannot be
implemented with TreeProcessor. Moreover, TreeProcessor has no notion of
taglib. Sorry ;)
<snip/>
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
XSP Languages, RE: [vote] move tree-processor in the main trunk
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Jason Foster [mailto:jafoster@uwaterloo.ca]
>
> <snip/>
>
> > Just to make things clear : sitemap is only one of the possible uses
of
> > the TreeProcessor : it's a generic framework for implementing
pipeline
> > assembly languages (hence "Processor") with an evaluation tree
(hence
> > "Tree").
> >
> > The supported languages are defined in treeprocessor.xconf or
> > cocoon.xconf, and the interpreted sitemap is "only" a particular
pipeline
> > assembly language implemented using this framework, but we could
> > implement others like Berin's proposal or Daniela Gehle's flowmap
(go
> > back to october 2001 in the archives to find them).
>
> Does that mean that XSPs that do not use compiled code fragments (Go
> Python! Go JavaScript! Go JavaBean! Down with Java source code!) can
be
> handled by the TreeProcessor?
XSPs written in not Java, but BSF languages, can be handled by XSP
mechanism without any problem. Existing XSP machinery is ready for other
languages, and this might be as compiled (into Java) languages and
interpreted ones. Do you know something better then IBM's BSF? I did not
found support for script pre-parsing, to improve performance.
> If this is the case, then the door is open for another aspect of
Cocoon to
> support the "dropping in" and automatic configuration of packages.
I'm
> not as up on XSP as I could be, but I get the impression that there is
> currently no support for "contracts" between the different taglibs.
What do you mean?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] move tree-processor in the main trunk
Posted by Jason Foster <ja...@uwaterloo.ca>.
<snip/>
> Just to make things clear : sitemap is only one of the possible uses of
> the TreeProcessor : it's a generic framework for implementing pipeline
> assembly languages (hence "Processor") with an evaluation tree (hence
> "Tree").
>
> The supported languages are defined in treeprocessor.xconf or
> cocoon.xconf, and the interpreted sitemap is "only" a particular pipeline
> assembly language implemented using this framework, but we could
> implement others like Berin's proposal or Daniela Gehle's flowmap (go
> back to october 2001 in the archives to find them).
Does that mean that XSPs that do not use compiled code fragments (Go
Python! Go JavaScript! Go JavaBean! Down with Java source code!) can be
handled by the TreeProcessor?
If this is the case, then the door is open for another aspect of Cocoon to
support the "dropping in" and automatic configuration of packages. I'm
not as up on XSP as I could be, but I get the impression that there is
currently no support for "contracts" between the different taglibs. If
the TreeProcessor supports it, we could package a taglib with a deployment
descriptor (XML Schema?), drop it into a TagLibs directory, and it would
all magically work without any fuss.
It might even work on WebLogic too :)
<snip/>
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] move tree-processor in the main trunk
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Ok,
>
>sitemap code generation is getting slower every day and is likely to
>become worse as we add more bugfixes and error generation.
>
>Clearly, developping on cocoon with 20 seconds delays between changes is
>a nightmare and would scare people away instantly.
>
>Now that we have a functional interpreted sitemap engine, I suggest we
>move this on the main trunk and keep improving on it from there.
>
+1
>Also, I would like to propose a name change: TreeProcessor isn't exactly
>self-explanatory as a 'sitemap interpreter'.
>
Just to make things clear : sitemap is only one of the possible uses of
the TreeProcessor : it's a generic framework for implementing pipeline
assembly languages (hence "Processor") with an evaluation tree (hence
"Tree").
The supported languages are defined in treeprocessor.xconf or
cocoon.xconf, and the interpreted sitemap is "only" a particular
pipeline assembly language implemented using this framework, but we
could implement others like Berin's proposal or Daniela Gehle's flowmap
(go back to october 2001 in the archives to find them).
Having this clear in mind, there's no problem to speak of "interpreted
sitemap".
>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!
>
The Processor used by Cocoon is a regular component : just change the
class of the <sitemap> in cocoon.xconf and you're done !
And if we decide to blast the compiled version, we just have to change
the default class in cocoon.roles. But let's both live together until
we're sure the interpreted version is bug-free.
>What do you think?
>
Sounds good :)
However, I'd like to propose some package renaming to better organize
things (inspired by some off-list discussion with Vadim) :
- org.apache.cocoon.components.treeprocessor : the TreeProcessor framework
- org.apache.cocoon.sitemap : classes common to both implementations
- org.apache.cocoon.sitemap.java : classes specific to the compiled version
- org.apache.cocoon.sitemap.tree : classes specific to the tree-based
version
Vadim proposed to insert "processor" before sitemap (i.e.
"org.apache.cocoon.processor.sitemap") to outline the fact that sitemap
is only one implementations of Processor among others, but I don't think
such a depth is necessary unless we think to have more than a dozen
different languages ;)
And also, we should start discussing the integration of schecoon and
interpreted sitemap, and more generally about Processor implementations
that coexist in the system. I was thinking about some ProcessorManager
or ProcessorSelector that any xxmap ('xx' = 'flow', 'site' or something
else) could query to get others xxmaps (e.g. a sitemap calling a
flowmap). I don't have clear thoughts about that, but it seems to me it
should be able to discriminate Processor instances by the language
(xxmap), the source file that defines it and the mount path (since a
subsitemap behaviour depends on its parents).
Thoughts ?
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: [vote] move tree-processor in the main trunk
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
>
> > From: giacomo [mailto:giacomo@apache.org]
> >
> > On Thu, 7 Feb 2002, Stefano Mazzocchi wrote:
> >
> > > Ok,
> > >
> > > sitemap code generation is getting slower every day and is likely to
> > > become worse as we add more bugfixes and error generation.
> >
> > The last major rewrite has introduced a boost in slownes.
>
> :(
>
> Giacomo,
>
> The slowness you are experiencing (I hope) has nothing to do with the
> rewrite itself, but with the syntax checks introduced into engine. If
> majority votes on removing these checks, I will be happy to remove them.
No, let's keep them in.
Vadim, I'm sure that Giacomo was not complaining, but just stating a
fact.
I think we are hitting the wall as far as on-fly compilation
technologies go, it's time to do something better.
--
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: [vote] move tree-processor in the main trunk
Posted by giacomo <gi...@apache.org>.
On Thu, 7 Feb 2002, Vadim Gritsenko wrote:
> > From: giacomo [mailto:giacomo@apache.org]
> >
> > On Thu, 7 Feb 2002, Stefano Mazzocchi wrote:
> >
> > > Ok,
> > >
> > > sitemap code generation is getting slower every day and is likely to
> > > become worse as we add more bugfixes and error generation.
> >
> > The last major rewrite has introduced a boost in slownes.
>
> :(
>
> Giacomo,
>
> The slowness you are experiencing (I hope) has nothing to do with the
> rewrite itself, but with the syntax checks introduced into engine. If
> majority votes on removing these checks, I will be happy to remove them.
It has clearly to do with the checkes introduced and I don't want them
to disappear because it can help writing correct sitemap now. So you get
my thanks making it happen even if we have to pay the obvious price for
it ;)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [vote] move tree-processor in the main trunk
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: giacomo [mailto:giacomo@apache.org]
>
> On Thu, 7 Feb 2002, Stefano Mazzocchi wrote:
>
> > Ok,
> >
> > sitemap code generation is getting slower every day and is likely to
> > become worse as we add more bugfixes and error generation.
>
> The last major rewrite has introduced a boost in slownes.
:(
Giacomo,
The slowness you are experiencing (I hope) has nothing to do with the
rewrite itself, but with the syntax checks introduced into engine. If
majority votes on removing these checks, I will be happy to remove them.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] move tree-processor in the main trunk
Posted by giacomo <gi...@apache.org>.
On Thu, 7 Feb 2002, Stefano Mazzocchi wrote:
> Ok,
>
> sitemap code generation is getting slower every day and is likely to
> become worse as we add more bugfixes and error generation.
The last major rewrite has introduced a boost in slownes.
> Clearly, developping on cocoon with 20 seconds delays between changes is
> a nightmare and would scare people away instantly.
C'mon, it's not that bad. I do develop on it and as long as you don't
have to clear your work directory it works just fine. There is no need
to restart Tomcat all the time anymore.
> Now that we have a functional interpreted sitemap engine, I suggest we
> move this on the main trunk and keep improving on it from there.
+1
> Also, I would like to propose a name change: TreeProcessor isn't exactly
> self-explanatory as a 'sitemap interpreter'.
Ok.
> Moreover, I'd love to be able to decide what to use (interpreted or
> compiled) from cocoon.xconf....
I thought is is already configurable in 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
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [vote] move tree-processor in the main trunk
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Ok,
>
> sitemap code generation is getting slower every day and is likely to
> become worse as we add more bugfixes and error generation.
>
> Clearly, developping on cocoon with 20 seconds delays between changes is
> a nightmare and would scare people away instantly.
>
> Now that we have a functional interpreted sitemap engine, I suggest we
> move this on the main trunk and keep improving on it from there.
>
+1
> Also, I would like to propose a name change: TreeProcessor isn't exactly
> self-explanatory as a 'sitemap interpreter'.
>
+1
> 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!
>
> What do you think?
>
Lets "get rid of that stupid javac!"!
I don't want to maintain two components for the same thing. This will end
up in synchronisation nightmares.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org