You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Steven Maring <St...@trcinc.com> on 2000/04/10 13:24:23 UTC
RE: Enhydra vs Cocoon - with new Cocoon idea
I'm testimate to that brother. I looked into Enhydra a while back and saw a
crapload (purely scientific term) of promises of having it become the
ultimate application server of web technology. But I became the typical
dear caught in the headlights of a strong marketing department. Despite the
OpenSource approach, it smelled oddly commercial. I got scared and ran. I
really don't know where they stand now, so I'm certianly not an expert. I
opted for a sense of prurity, so I use Jonas by itself as an EJB application
server, and Jonathan by itself as an ORB (ocassionaly VisiBroker for
customer demands). For a complete distributed web application solution, I
find that Cocoon, Tomcat, Jonas, and Jonathan all work rather nicely as they
are. Not that there is not room for improvement. :-)
I'm not sure if it would be wise for Cocoon to try to become an EJB
container as well though.
Here's an idea for Cocoon though. How about a way to stick a document
manager at the front of the process that can check the state of change on
original data, and point a reference to a pre-Cocooned xhtml page if no
state has changed. I'm just thinking of ways to limit the requirement for
processing, if even just formatting, on every request. i.e. Have a sort of
automated change management procedure that can automatically start the
generation of new *.html files from various events. Those events could
either be timed, or based on file changes, like Suzie from PR just changed
an aricle in the XML.
The thought is that for some pages, they may only change once in a hundred
requests, and it seems silly to process every request in a servlet container
if the page never changed.
--Steve Maring
-----Original Message-----
From: Stefano Mazzocchi
To: cocoon-users@xml.apache.org
Sent: 4/9/00 7:26 AM
Subject: Re: Enhydra vs Cocoon
"David H. Young" wrote:
[...]
> As always, it comes down to picking your poison. And figuring out the
> nature of your project, the capabilities of your team and how you
allocate
> different groups to different parts of the project.
Totally true.
Anyway, to be extremely honest with you, I don't have _any_ problem to
have open source projects that are based on the same technology (Enhydra
is based on Apache JServ) and are competing in other grounds (XML).
What I found _offensive_ and utterly provocative is that "leading"
marketing shit in all your advertising. I also find "scary" the need for
an open source project to be -advertised- on slashdot to gain momentum.
I'll tell you a story: NewAtlanta people used to have a signature on
their emails such as "the leading providers for servlet technology".
When people started to laught at that, they removed it.
Once the community is laughing at you, it's pretty hard to back it up,
don't 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
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: Enhydra vs Cocoon - with new Cocoon idea
Posted by Stefano Mazzocchi <st...@apache.org>.
Mike Engelhart wrote:
>
> Stefano Mazzocchi wrote:
>
> > Strangely enough, there are very little known bugs in Cocoon.
> Isn't that because cocoon's wrap bugs so you can't see them??
> Sorry...
>
> :-)
Probably so :)
Seriously, I am concerned about this "wrap the bug and hide it"
perception that I'm having too... I do have plans for much better
usability and debugging once we have the Cocoon2 architecture in place.
It just doesn't make sense to work on something that you already planned
to throw away (I mean cocoon1), do you think it's reasonable?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Enhydra vs Cocoon - with new Cocoon idea
Posted by Mike Engelhart <me...@earthtrip.com>.
Stefano Mazzocchi wrote:
> Strangely enough, there are very little known bugs in Cocoon.
Isn't that because cocoon's wrap bugs so you can't see them??
Sorry...
:-)
Mike
Re: Enhydra vs Cocoon - with new Cocoon idea
Posted by Stefano Mazzocchi <st...@apache.org>.
Ulrich Mayring wrote:
>
> Stefano Mazzocchi wrote:
> >
> > I would never be able to sell anything, I'm too honest. That's why you
> > get my software for free :)
>
> For free is nice, but OpenSource is even nicer :)
Uh, that's part of the deal. I'm too honest to pretend I can give you
software that works... so I give you the ability to fix it for yourself
:)
Strangely enough, there are very little known bugs in Cocoon.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Enhydra vs Cocoon - with new Cocoon idea
Posted by Ulrich Mayring <ul...@denic.de>.
Stefano Mazzocchi wrote:
>
> I would never be able to sell anything, I'm too honest. That's why you
> get my software for free :)
For free is nice, but OpenSource is even nicer :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Enhydra vs Cocoon - with new Cocoon idea
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Maring wrote:
> Here's an idea for Cocoon though. How about a way to stick a document
> manager at the front of the process that can check the state of change on
> original data, and point a reference to a pre-Cocooned xhtml page if no
> state has changed. I'm just thinking of ways to limit the requirement for
> processing, if even just formatting, on every request. i.e. Have a sort of
> automated change management procedure that can automatically start the
> generation of new *.html files from various events. Those events could
> either be timed, or based on file changes, like Suzie from PR just changed
> an aricle in the XML.
This will be done with the Stylebook integration with Cocoon2. It's a
feature that is already planned.
> The thought is that for some pages, they may only change once in a hundred
> requests, and it seems silly to process every request in a servlet container
> if the page never changed.
Totally.
Unfortunately, to avoid the cocoon servlet being called at all, you
would need something like a mod_cocoon that uses the web server cache to
store the page and avoids calling it back... but something like this is
very much like a proxy and cannot be more powerful unless it does go
back to the servlet to check if the pipeline must be regenerated.
It's much more tricky than it seems, but with stylebook capabilities +
time-to-live of page + a good proxy up front + cocoon dynamically
adapting cache, I think you can easily handle _huge_ loads with not many
processing resources.
At least, I've seen what it takes to handle 100 dynamic req/sec on an
Oracle Application Server and Cocoon can already kick ass on that,
today. Gee, and I around saying that Cocoon1 is a crappy design.
I would never be able to sell anything, I'm too honest. That's why you
get my software for free :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Enhydra vs Cocoon - with new Cocoon idea
Posted by Stefano Mazzocchi <st...@apache.org>.
Paul Russell wrote:
>
> Steve wrote:
> > I'm not sure if it would be wise for Cocoon to try to become an EJB
> > container as well though.
>
> Totally agree. Cocoon is a very very good front end processing package,
> JonAS is a pretty good EJB container, there is nothing to stop people
> tying the two together. I think the key to making this work is to keep
> everything as abstract as possible, and from what I've seen, both Pier
> and Stefano are *very* good at this already. I'd *hate* to see cocoon
> turn into something it isn't.
Indeed, dude!
XSP already give you the ability to match EJB capabilities by placing
custom java code that does that, but in the future we might provide EJB
taglibs that do that for you with a bunch of easily usable tags instead.
Anyway, the architecture is already flexible enough to stand anything
you really want to do... without placing everything into the Cocoon
project.
In fact, smaller decoupled projects mean faster release cycles, better
stability and better usability.
True, installation is sometimes penalized by this, but we proposed the
Avalon framework to fix exactly that (see java.apache.org/framework/).
Hey, there is _so_ much work yet to do... but all the Apache projects
are "slowly" converging together to a unified server architecture that
would be useful for both users and developers.
And I never said that cocoon was finished or perfect.
Wheneven I say that, please, kick me in the ass big time! :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Enhydra vs Cocoon - with new Cocoon idea
Posted by Paul Russell <Pa...@uea.ac.uk>.
Steve wrote:
> I'm not sure if it would be wise for Cocoon to try to become an EJB
> container as well though.
Totally agree. Cocoon is a very very good front end processing package,
JonAS is a pretty good EJB container, there is nothing to stop people
tying the two together. I think the key to making this work is to keep
everything as abstract as possible, and from what I've seen, both Pier
and Stefano are *very* good at this already. I'd *hate* to see cocoon
turn into something it isn't.
> The thought is that for some pages, they may only change once in a hundred
> requests, and it seems silly to process every request in a servlet container
> if the page never changed.
Indeed. There's probably a case for having a generic SAX stream caching
system to cache intermediate results (probably as DOM trees, in reality)
too, although this is somewhat more difficult to implement without eating
memory at a scary, scary rate.
Paul