cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [RT] Is Cocoon Obsolete?
Date Sun, 02 Oct 2005 08:14:06 GMT
On 30.09.2005 23:57, Stefano Mazzocchi wrote:

> Over the last 6 months, I worked pretty heavily on Mozilla as a platform.

As you might know I (or we at Virbus at that time) have created an 
application built on Mozilla [1] [2].

> but most important, is that pretty much everything that cocoon was born 
> to do, you can now do it in firefox directly.

And we also perceived the fact that Cocoon to a large extent was no 
longer used in the way it was targeted. AFAIR the only "classical" 
pipeline was a serializing of business objects to XML and transforming 
these structures to RDF. The other tasks could have been done by other 
software too, e.g. delivering static resources. So, yes, I can agree to 
a certain extent to your thoughts.

> I do that for my latest web sites and the more I learn how to driven the 
> client, the less I feel the need for advanced server frameworks. Is it 
> just me?  Is client side advancement making cocoon and all its machinery
> to compensate for advanced web client obsolete and archaic?

No. Cocoon is not and will not become obselete IMO. First you need a 
server framework, somewhat has still to respond to requests. Now must it 
be an advanced one? What's advanced? Is Struts advanced? Must it be Cocoon?

At least I prefer it by far. Cocoon is the most flexible framework and 
is probably the one that best suits to the new requirements. So Cocoon 
has maybe to move its focus - for the case rich clients really take off. 
But I can see that frameworks like Struts with a focus on just view and 
controller might become obsolete.

For Cocoon removing the creation of UIs from the server still leaves 
enough room as integration platform (serializing business objects, 
getting data from anywhere) or for fulfilling non-functional 
requirements, e.g. caching.


[2] (The app is now sold by 
eWerk and maintained by a subcontractor.)

View raw message