cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [RT] Is Cocoon Obsolete?
Date Sun, 02 Oct 2005 19:02:12 GMT
Hi Stefano:

I am glad to see you again on the list. :-)

2 days ago, I wrote an answer with some of the arguments that other 
people already replied to this thread. Between them:

1. Mobile devices taking off --> still a lot of other platforms to 
publishing.
2. Nature of software evolution in the LAN: from dumb terminals to rich 
client server architecture.

I understand your point about cocoon obsoleteness, if we were a "web 
client" community. As a really early adopter [1], maybe cocoon is no 
longer part of the cutting edge technology anymore, but just wait to 
Osgi and we can talk again about this topic! ;-)

It is simply because now there are other players trying to do (or 
already are doing) the same as me. We know the rich client is the next 
big thing in the web client side and that it is really getting hot! But 
this is IMHO, not new and at the end this is just another client, 
nothing more! Exactly as XUL, there are also a lot of other interesting 
technologies waiting to be landed (more digested and better covered) by 
the both worlds (client and server) as SVG, OpenDocument, between others.

Hence, from a server-side developer POV, IMHO, rich client will still 
need servers to deliver content. Because we are "a server framework 
community", then rich clients are just another type of client to whom 
cocoon need to serve! ;-)

I was also thinking if continuations are obsolete too? I don't think so. 
I believe even in the rich clients we still need to manage more easily 
current client states and the next allowed steps for them. IMHO, they 
are still event-drived, isn't?. Then, we cannot just keep the server 
open to whatever request they want to send back. ;-) I think this is 
also very important from the server security POV. AFAIK, in firefox we 
can get client's source code very easily. Well, I foresee "smart users - 
black hats users" "playing - tweaking" the rich client source code and 
sending not expected requests back to the server! This is one of the 
thing I don't saw covered by the maketing campaign of rich web client. 
For the records, I am not against web rich clients. But, will be pretty 
sad if we have a really dumb server just waiting to serve any requests 
comming from a client.

Hence IMHO, all this, this does not make cocoon become obsolete. The 
only thing we need to do is to make cocoon serve content for rich 
clients and we have the job done! This is the new challenge we saw for 
cocoon community long time ago. BTW, we already wanted to make this 
happens [2]. Unfortunately, the project failed. But this does not mean 
we cannot target in that direction too. BTW, this issue is too hot that, 
I found a new interesting link [3], I didn't check is this is really an 
active project.

Also, from an client-side early adopter POV this is really cool to be 
there developing the new rich clients for the web . There is already a 
lot of new interesting and cool stuff + a lot of things need to be done. 
But still here, in the server side, is a lot of cool things to be done 
too. Keep a server product "up to date" with the current trends is also 
a very cool challenge! Don't you think that? ;-)

Best Regards,

Antonio Gallardo.

[1] on wich side - client or server  - is not clear to me from your 
mail, but lets assume it is from the server side
[2] http://wiki.apache.org/cocoon/CocoonCFormsXULUIProject
[3] http://cforms-xul.tigris.org/


Mime
View raw message