cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RF] Chainsaws and Seeds
Date Sat, 10 Dec 2005 11:20:55 GMT
Niclas Hedhman wrote:
> On Friday 09 December 2005 02:21, Stefano Mazzocchi wrote:
> And in terms of moving the "equi-cost" point to the left, there are two 
> fundmentally different variables to consider.
> for instance, if t
>               ____
>   y = a *  b / x  `
>            \/
> total cost of ownership (y)
>      ^
>      |                   o
>      |            o      |
>      |       o           |
>      |    o              v
>      |  o  \             2.
>      | o    \
>      |o      1.
>      +---------------------->
>                         complexity (x)
>  1. Essential focus on lessening the threshold, i.e. lower "a".
>  2. Increasing the power of the functionality that are required for really
>     complex systems, i.e. increasing the root base.
> Often, these are also interlinked, and it is important that the lowering of 
> "a" doesn't make ( b < 1 )...
> I think everyone are at this point focusing on 1. The "market" talks about 
> "quick starters" and Cocoon peeps wants to "me too" in that area. I don't 
> give a flying fart about RubyOnRail as my gut says that it doesn't make it 
> easier to become the next Rembrandt, only providing me with more cryons than 
> the other kids.

Good one :-)

> I think Stefano's RF is great. 


> He challenges people's presence and 
> motivations. If you want to do weblog apps - GO. If you want to DB record 
> viewer app - GO. If you want JAWA (Just Another Web Application) - GO. 
> GO - because there are 50 other frameworks out there, all of them with their 
> strengths, weaknesses and hype. I am sure there is some that suits YOU, as 
> well as me. JAWA is not why I keep my interest...
> The reason to stay, is not to compete with Struts, Tapestry, Wicket, RoR, PHP 
> and every other JAWA framework out there.
> The orthogonality of Cocoon has "died". Noone talks about views. Noone 
> highlights the ability to serve same content to many user agents. Noone is 
> interested in truly useful smaller components. Noone cares about the 
> developer vs designer vs deployer roles.

Hmmm, interesting, didn't see it this way. I wonder if it's because the 
real life forces those role to hybridize over and over, if we didn't 
make the right choice in separating them or because really nobody cares.

If nobody really cares, then I wonder what in hell are we still thinking 
in terms of SoC!

> I am predicting that the next round of waves will not be around delivering 
> HTML or XML to web browsers, AJAX or not. It will center around dedicated 
> clients. And not _any_ client - but the Mobile clients.

I very strongly disagree. Mobiles are getting richer and richer, and the 
HTML browser software is becoming more and more commoditized. It might 
be easier for everybody to deliver XHTML with Ajax-retrieved CSS and 
content than to do it the other way around.

But the important point is not that you can do it, it's all those 
borderline cases where you *can'* and, therefore, your complexity starts 
to increase dramatically.

Cocoon will help moving stuff back to the server with very reasonable 
costs and move stuff from the server to the client gradually.

*that* is, IMO, the real need: a web framework that is powerful and 
flexible, yet easy to use, that allows to position your web application 
on all possible shades between a controller that stays most on the 
client or most on the server, with the ability to fine-tune that over 
time with as much ease.

> And this is a lot more interesting to Cocoon than one first realizes.
>  1. Cocoon is already equipped to serve mobile clients, both WML and binary
>     formats. No change required.

Sure, but that's really not that hard to achieve.

>  2. The most important aspect is the ability to generate media for different
>     device models. No change required.

Pipelines are first class citizens in Cocoon land, but you are talking 
to one use of it, one that makes you happy. I'm happy if that happens, 
but there are others. The important part is to keep the pipeline 
machinery as first class, yet make it easier to use even in other 
usecases. See Sylvain's proposal for dynamic and scripted pipelines.

>  3. Americans have no clue about what is about to happen. Europeans are better
>     prepared, and Cocoon is apparently a very European project.

That's complete bullshit. It is true that multi-modal appeal appears 
more in Europe than in the US, but as I said about, you might find that 
the complexity of multi-modality brings uniformity to the client (as it 
happens on the web) instead of bringing more complexity in the server 
side rendering engines, especially now that Mozilla Minimo and stuff 
like that are emerging and that mobiles (in order to run powerful games) 
will have more and more RAM and bigger screens.

> So, all of you who wants JAWA, Cocoon may not be the best tool. I don't think 
> we should even try to become the best. Cocoon is already great in many 
> aspects. We should concentrate on this, and become the defacto standard for 
> mobile backends.

I personally don't give a rat's ass about that. What you use it *FOR* is 
your problem. The great thing about open source is that you don't need 
a stinking mission statement to get money from VC, you just need to sit 
down and code and put your code where you mouth is.

So, if that's what you need and that is what you believe, great, use it 
for that and send patches when it doesn't do what you expect. Period.

As I said, cocoon is designed for situations where the number of people 
involved, the number of technologies involved, the number of existing 
legacy, the number of future complexity is so high that other 
technologies don't work.

Mobile portals? sure, one of them. Banking data interchange? yup. Pharma 
  and Avionic 1000-pages long manual creation and management? you got 
it. Intranets for fortune 500 companies? yup.

These are all applications where Cocoon has shined. Do you see the pattern?

> Finally, my take on what "Cocoon Really Needs".
> Cocoon needs a New Vision Statement. One paragraph of what Cocoon is all 
> about, that blows my (the user's) mind away. 

> Cocoon needs better Marketing. Struts didn't become Struts by developers 
> complimenting each other on how great they were. Grab the opportunity of 
> becoming the mobile backend 'standard'.

> Cocoon needs new Architecture. Marc's "to the point" list of how to get that 
> organized is a good starting point.
> Cocoon needs better Documentation. Yeah, yeah, I know the story ;o)

Cocoon need less people that write email and don't write code, myself 


View raw message