You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/03/29 17:51:39 UTC
Re: strange resons not going beta (was Re: C2: trouble getting streaming
to work as expected)
Giacomo Pati wrote:
>
> Quoting Berin Loritsch <bl...@apache.org>:
> >
> > No that isn't. Cocoon 2 is still (for some strange reason) considered
> > Alpha software, so there are no direct downloads.
>
> This is the first time I've read that the missing features (aggregation and
> caching) are strange reasons not going beta/production with Cocoon 2. Let me
> check this out. Who else finds this is strange.
>
> 1. Can you imagine that C1 users today will switch to C2 without a cache?
>
> The fact is that C2 cannot compete with C1 (with cache enabled)
> for static content delivery. This might lead to the situation
> that we will support and maintain two versions at the same time.
> C1 for faster static content delivery and C2 for dynamic publishing.
Regarding Cache on C2. Cocoon 2 is fast enough on my test systems and
scalable enough on my systems that cache isn't critical. We are talking
blazing. Cocoon 1 needs cache to even be useful--this is simple a state
of DOM vs. SAX architectures and the speed of the libraries we are using.
Cocoon 1 has discrete produce/process/format stages, while Cocoon 2 (due
to the event based SAX model) does generate/transform/serialize in each
event. The stages are performed in effect simultaneously.
Aggregation would be *nice* and would make my life easier, but they aren't
*critical*. Cocoon 2 is very fast and very stable. Those two things
make Cocoon 2 very attractive. To my superiors, upgrading to at least
a Beta status would be a feature they can sell better than anything
dubbed "alpha" quality. Why? Thank Microsoft. Microsoft Betas are worse
than most of Open Source's Pre-Alpha statuses.
> 2. Is content aggregation a feature we need to go beta/production?
>
> I've only follow Stefano reasoning that those features are needed to go
> beta/production. But you all can convice me to change my mind :) If most of you
> find these features are not needed for going beta/production we should ask on
> the user list what those people think about. I know C2 is very stable on
> what is implemented so far from projects I've realized with it (only dynamic
> systems which doesn't need caching). We all know that content aggregation will
> be a very cool feature to cut down your pages into smaller pieces collected from
> different sources almost like browser use HTML frames but with a total different
> granularity (frame technology on the server side). And thus having a cache can
> boost performance of such aggregation tremendously.
>
> So, what are you oppinions on this?
Me opinionated? (You know me so well :P).
Again, content aggregation will be a tremendous boon. Don't get me wrong.
It is a need. But I don't think that delaying beta because of the missing
feature is right either. I think that the Cache and Content Aggregation
aspects work well together. It will be hard to have a well performing
Content Aggregation system with sufficient granularity without caching.
I also know that if the aggregation system is too granular, it will be
abused and used for something that stylesheets would be better suited for.
As of right now, If I were to pit Cocoon 2 against ColdFusion (which does
a certain amount of caching BTW) with the ability to "skin" the site,
Cocoon 2 would win (assuming the same hardware). Some people will find
this hard to swallow, so I will break down the reasons why.
1) In order for ColdFusion to be flexibly "themed", you have to use allot
of <cfinclude> statements or create your own custom tags. ColdFusion
does cache, but it also checks the filesystem for each file. If the
files are small enough, then the cache actually slows things down.
2) ColdFusion Script gets slower and slower as it gets more complicated.
Now that you must explicitly lock session, application, and server
variables, performance really suffers.
3) Cocoon 2 XSP pages are compiled--while the first access can take upwards
of 30 seconds for a very complicated page, each additional access is
amazingly quick.
4) Datasources are handled differently between the two. ColdFusion uses
ODBC and Cocoon uses JDBC. For vendors that supply JDBC 2.0 compliant
drivers, I have found that they are much faster. This statement makes
the assumption that the communication with the database is over
ethernet and using the database's native protocol. ColdFusion does
cache datasources (as does Cocoon), but it is still slower.
Real performance differences on pages of similar complexity:
ColdFusion: 987ms/access
Cocoon 2: 324s/access
Both scale very well under load, but Cocoon's installation is far easier
than ColdFusion on a UNIX box.
The bottom line is that when Cocoon finally upgrades from "Alpha" to
"Beta" it upgrades from a "near impossible"/"difficult" sale to a
"mildly difficult"/"possible" sale. It is a core piece of technology
that we are selling to our client, so it will add that bolster of
confidence that will be needed when we present the final product to
them.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting streaming to work as expected)
Posted by Stuart Roebuck <st...@adolos.co.uk>.
Couldn't a 2.0aX release be made available for download. The nightly
build idea is handy for some folk but it doesn't resolve concerns about
stability. If a particular alpha release can be defined as a milestone
and released as a numbered alpha release and made available directly off
the C2 website, then this could instill some confidence without forcing C
2.0 to be cacheless and CA less.
Stuart.
On Friday, March 30, 2001, at 11:54 am, Giacomo Pati wrote:
> Quoting Santiago Gala <sg...@hisitech.com>:
>
>> Giacomo Pati wrote:
>>
>>> Santiago Gala wrote:
>>>
>>>> I agree, except for some SVG examples, for instance the svg-welcome.
>> A
>>>> cache would be great to have some kinds of processing, like svg or
>> pdf.
>>>>
>>>> I would sell very well an automated generation of graphic navigation
>>>> bars, for instance, but that calls for a cache, obviously.
>>>
>>>
>>> For these types of caching you best put C2 behinde a proxy server.
>>>
>>
>> Or even configuring a "Expires:" Header, so that the client caches it.
>> But this would defeat part of the dynamic nature of some menus like
>> these.
>>
>> BTW, is there any simple way that cocoon controls "If-modified-since:"
>> headers before the cache is in place? I imagine that part of the caching
>>
>> subsystem will/could take care of these shortcuts, not even delivering
>> content.
>
> The readers (ResourceReader, DatabaseReader) we have are already handling
> "If-modified-since" requests and are able to accept a expires parameter to
> specify the TTL of a produced resource.
>
> Giacomo
>
>> Again, I'm not protesting (neither I have any authority for doing it :).
>> Just pointing that cache is required for a "final" c2 that is usable.
>> That it happens under 2.0 or 2.1, or even that you release (as Donald
>> suggested) nightly c2aX builds, instead of fully freezing APIs, that's
>> your decision.
>>
>> On the other side, I agree that C2 needs more visibility, and it needs
>> it sooner than after. Freezing 2.0 APIs, and then, it caching needs API
>> changes, releasing it as 2.1 could be a solution.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS http://www.adolos.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting streaming to work as expected)
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Santiago Gala <sg...@hisitech.com>:
> Giacomo Pati wrote:
>
> > Santiago Gala wrote:
> >
> >> I agree, except for some SVG examples, for instance the svg-welcome.
> A
> >> cache would be great to have some kinds of processing, like svg or
> pdf.
> >>
> >> I would sell very well an automated generation of graphic navigation
> >> bars, for instance, but that calls for a cache, obviously.
> >
> >
> > For these types of caching you best put C2 behinde a proxy server.
> >
>
> Or even configuring a "Expires:" Header, so that the client caches it.
> But this would defeat part of the dynamic nature of some menus like
> these.
>
> BTW, is there any simple way that cocoon controls "If-modified-since:"
> headers before the cache is in place? I imagine that part of the caching
>
> subsystem will/could take care of these shortcuts, not even delivering
> content.
The readers (ResourceReader, DatabaseReader) we have are already handling
"If-modified-since" requests and are able to accept a expires parameter to
specify the TTL of a produced resource.
Giacomo
> Again, I'm not protesting (neither I have any authority for doing it :).
> Just pointing that cache is required for a "final" c2 that is usable.
> That it happens under 2.0 or 2.1, or even that you release (as Donald
> suggested) nightly c2aX builds, instead of fully freezing APIs, that's
> your decision.
>
> On the other side, I agree that C2 needs more visibility, and it needs
> it sooner than after. Freezing 2.0 APIs, and then, it caching needs API
> changes, releasing it as 2.1 could be a solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting streaming to work as expected)
Posted by Santiago Gala <sg...@hisitech.com>.
Giacomo Pati wrote:
> Santiago Gala wrote:
>
>> Berin Loritsch wrote:
>>
>>
>>> Giacomo Pati wrote:
>>>
>>>
>>>> Quoting Berin Loritsch <bl...@apache.org>:
>>>>
>>>>
>>>>> No that isn't. Cocoon 2 is still (for some strange reason) considered
>>>>> Alpha software, so there are no direct downloads.
>>>>
>>>> This is the first time I've read that the missing features (aggregation and
>>>> caching) are strange reasons not going beta/production with Cocoon 2. Let me
>>>> check this out. Who else finds this is strange.
>>>>
>>>> 1. Can you imagine that C1 users today will switch to C2 without a cache?
>>>>
>>>> The fact is that C2 cannot compete with C1 (with cache enabled)
>>>> for static content delivery. This might lead to the situation
>>>> that we will support and maintain two versions at the same time.
>>>> C1 for faster static content delivery and C2 for dynamic publishing.
>>>
>>>
>>> Regarding Cache on C2. Cocoon 2 is fast enough on my test systems and
>>> scalable enough on my systems that cache isn't critical. We are talking
>>> blazing. Cocoon 1 needs cache to even be useful--this is simple a state
>>> of DOM vs. SAX architectures and the speed of the libraries we are using.
>>> Cocoon 1 has discrete produce/process/format stages, while Cocoon 2 (due
>>> to the event based SAX model) does generate/transform/serialize in each
>>> event. The stages are performed in effect simultaneously.
>>>
>>
>> I agree, except for some SVG examples, for instance the svg-welcome. A
>> cache would be great to have some kinds of processing, like svg or pdf.
>>
>> I would sell very well an automated generation of graphic navigation
>> bars, for instance, but that calls for a cache, obviously.
>
>
> For these types of caching you best put C2 behinde a proxy server.
>
Or even configuring a "Expires:" Header, so that the client caches it.
But this would defeat part of the dynamic nature of some menus like these.
BTW, is there any simple way that cocoon controls "If-modified-since:"
headers before the cache is in place? I imagine that part of the caching
subsystem will/could take care of these shortcuts, not even delivering
content.
Again, I'm not protesting (neither I have any authority for doing it :).
Just pointing that cache is required for a "final" c2 that is usable.
That it happens under 2.0 or 2.1, or even that you release (as Donald
suggested) nightly c2aX builds, instead of fully freezing APIs, that's
your decision.
On the other side, I agree that C2 needs more visibility, and it needs
it sooner than after. Freezing 2.0 APIs, and then, it caching needs API
changes, releasing it as 2.1 could be a solution.
> Giacomo
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting streaming to work as expected)
Posted by Stuart Roebuck <st...@adolos.co.uk>.
A lot of the work we are doing couldn't go prime-time on live C2 without a
cache (we currently output content from C2 and serve it statically). That'
s not specifically the fault of Cocoon but inherent in the nature of some
of our generators and the level of multiple pass XSLT processing we do.
We could work round it by building our own cache and moving our XSLT code
more from code maintainability towards code efficiency, but a C2 cache
would make that work redundant, so we're not too keen.
I'm not really pushing things either way, but I thought it was worth
indicating that there are folk out there who would put C2 caching up there
as a critical feature.
Stuart.
On Friday, March 30, 2001, at 06:22 am, Giacomo Pati wrote:
> Santiago Gala wrote:
>>
>> Berin Loritsch wrote:
>>
>>> Giacomo Pati wrote:
>>>
>>>> Quoting Berin Loritsch <bl...@apache.org>:
>>>>
>>>>> No that isn't. Cocoon 2 is still (for some strange reason)
>>>>> considered
>>>>> Alpha software, so there are no direct downloads.
>>>>
>>>> This is the first time I've read that the missing features
>>>> (aggregation and
>>>> caching) are strange reasons not going beta/production with Cocoon 2.
>>>> Let me
>>>> check this out. Who else finds this is strange.
>>>>
>>>> 1. Can you imagine that C1 users today will switch to C2 without a
>>>> cache?
>>>>
>>>> The fact is that C2 cannot compete with C1 (with cache enabled)
>>>> for static content delivery. This might lead to the situation
>>>> that we will support and maintain two versions at the same time.
>>>> C1 for faster static content delivery and C2 for dynamic
>>>> publishing.
>>>
>>>
>>> Regarding Cache on C2. Cocoon 2 is fast enough on my test systems and
>>> scalable enough on my systems that cache isn't critical. We are talking
>>> blazing. Cocoon 1 needs cache to even be useful--this is simple a state
>>> of DOM vs. SAX architectures and the speed of the libraries we are
>>> using.
>>> Cocoon 1 has discrete produce/process/format stages, while Cocoon 2 (due
>>> to the event based SAX model) does generate/transform/serialize in each
>>> event. The stages are performed in effect simultaneously.
>>>
>>
>> I agree, except for some SVG examples, for instance the svg-welcome. A
>> cache would be great to have some kinds of processing, like svg or pdf.
>>
>> I would sell very well an automated generation of graphic navigation
>> bars, for instance, but that calls for a cache, obviously.
>
> For these types of caching you best put C2 behinde a proxy server.
>
> Giacomo
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS http://www.adolos.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting
streaming to work as expected)
Posted by Giacomo Pati <gi...@apache.org>.
Santiago Gala wrote:
>
> Berin Loritsch wrote:
>
> > Giacomo Pati wrote:
> >
> >> Quoting Berin Loritsch <bl...@apache.org>:
> >>
> >>> No that isn't. Cocoon 2 is still (for some strange reason) considered
> >>> Alpha software, so there are no direct downloads.
> >>
> >> This is the first time I've read that the missing features (aggregation and
> >> caching) are strange reasons not going beta/production with Cocoon 2. Let me
> >> check this out. Who else finds this is strange.
> >>
> >> 1. Can you imagine that C1 users today will switch to C2 without a cache?
> >>
> >> The fact is that C2 cannot compete with C1 (with cache enabled)
> >> for static content delivery. This might lead to the situation
> >> that we will support and maintain two versions at the same time.
> >> C1 for faster static content delivery and C2 for dynamic publishing.
> >
> >
> > Regarding Cache on C2. Cocoon 2 is fast enough on my test systems and
> > scalable enough on my systems that cache isn't critical. We are talking
> > blazing. Cocoon 1 needs cache to even be useful--this is simple a state
> > of DOM vs. SAX architectures and the speed of the libraries we are using.
> > Cocoon 1 has discrete produce/process/format stages, while Cocoon 2 (due
> > to the event based SAX model) does generate/transform/serialize in each
> > event. The stages are performed in effect simultaneously.
> >
>
> I agree, except for some SVG examples, for instance the svg-welcome. A
> cache would be great to have some kinds of processing, like svg or pdf.
>
> I would sell very well an automated generation of graphic navigation
> bars, for instance, but that calls for a cache, obviously.
For these types of caching you best put C2 behinde a proxy server.
Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting streaming to work as expected)
Posted by Santiago Gala <sg...@hisitech.com>.
Berin Loritsch wrote:
> Giacomo Pati wrote:
>
>> Quoting Berin Loritsch <bl...@apache.org>:
>>
>>> No that isn't. Cocoon 2 is still (for some strange reason) considered
>>> Alpha software, so there are no direct downloads.
>>
>> This is the first time I've read that the missing features (aggregation and
>> caching) are strange reasons not going beta/production with Cocoon 2. Let me
>> check this out. Who else finds this is strange.
>>
>> 1. Can you imagine that C1 users today will switch to C2 without a cache?
>>
>> The fact is that C2 cannot compete with C1 (with cache enabled)
>> for static content delivery. This might lead to the situation
>> that we will support and maintain two versions at the same time.
>> C1 for faster static content delivery and C2 for dynamic publishing.
>
>
> Regarding Cache on C2. Cocoon 2 is fast enough on my test systems and
> scalable enough on my systems that cache isn't critical. We are talking
> blazing. Cocoon 1 needs cache to even be useful--this is simple a state
> of DOM vs. SAX architectures and the speed of the libraries we are using.
> Cocoon 1 has discrete produce/process/format stages, while Cocoon 2 (due
> to the event based SAX model) does generate/transform/serialize in each
> event. The stages are performed in effect simultaneously.
>
I agree, except for some SVG examples, for instance the svg-welcome. A
cache would be great to have some kinds of processing, like svg or pdf.
I would sell very well an automated generation of graphic navigation
bars, for instance, but that calls for a cache, obviously.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting
streaming to work as expected)
Posted by Peter Donald <do...@apache.org>.
Hi,
Just a note - I think it would not be wise to go beta until the
jakarta-avalon CVS goes beta. If you would be willing to wait about 1 month
I think we could put that CVS into a beta state. I will also write a python
script to help convert any applications based on cocoon2. There is still a
few discussion points that need to be addressed but I think that it should
be possible.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble gettingstreaming
to work as expected)
Posted by Berin Loritsch <bl...@apache.org>.
Matt Sergeant wrote:
>
> On Thu, 29 Mar 2001, Berin Loritsch wrote:
>
> > Real performance differences on pages of similar complexity:
> >
> > ColdFusion: 987ms/access
> > Cocoon 2: 324s/access
>
> Ouch, I guess you're sticking with ColdFusion then :-)
<g> As soon as I found out you can separate style from logic
I was on the Cocoon bandwagon (Cocoon ~1.5). Back then, there
wasn't much performance difference but ColdFusion scaled better.
I like the fact that I can understand my code now. I also
like the fact that if we sell the same solution to more than
one customer, we can make them feel like they have another
product entirely--and our maintenance costs are lower with
Cocoon :).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: strange resons not going beta (was Re: C2: trouble getting
streaming to work as expected)
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 29 Mar 2001, Berin Loritsch wrote:
> Real performance differences on pages of similar complexity:
>
> ColdFusion: 987ms/access
> Cocoon 2: 324s/access
Ouch, I guess you're sticking with ColdFusion then :-)
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org