Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3AC35A0B.3A057996@apache.org>
Date: Thu, 29 Mar 2001 10:51:39 -0500
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: strange resons not going beta (was Re: C2: trouble getting
 streaming
 to work as expected)
References: <19C34CD863B1D4118E2800508BAF663A11C1F1@STONE>
 <3AC33BEF.5035E8AD@apache.org> <985875694.3ac344ef01eb2@mail.otego.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Giacomo Pati wrote:
> 
> Quoting Berin Loritsch <bloritsch@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