cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RF] Chainsaws and Seeds
Date Thu, 08 Dec 2005 18:21:09 GMT


I've followed the results of my "shaking the tree" last month with a mix 
of worry, amusement, anger, hope and despair, not necessarily in this order.

RF stands for "random feelings". The web is undergoing a phase 
transition, from a web of pages to a web of data and services. Those who 
think ajax and ruby on rails complete such phase transition will hit a 
wall so tall and thick they will have to reconsider even their names.

As the "cocoon is obsolete" thread showed, the need for a web server 
framework is not gone, it's just changed. Forces are moving the tectonic 
plates of the various technologies (and the socio-economies around it) 
and companies like Google and Yahoo! inject water into the faults, and 
they don't care if the various earthquakes destroy things around them.

At the end of the day, the server side has a unique feature, is more 
centralized than the client side. Even a massive clusters like Google or 
Yahoo! work because the uniformity of their infrastructure is incredibly 

By moving code on the client side, you enter an ecosystem with an 
increasing (and unlikely decreasing from now on) variety. This will 
increase complexity.

One of the places where Cocoon proved to be incredibly successful was 
the multi-modal market, where the different modes turned out to be tens 
of not hundreds (here I'm talking about the mobile portal world and the 
machine2machine world).

As much as cocoon is not obsolete, the web 1.0 is not obsolete, because 
"web 2.0" doesn't exist! it's a marketing meme, it's nothing but a step 
in the direction of a vision of a web of data and services, some of 
which contains graphical information (therefore is suitable for 
screen/audio/3d rendering) some doesn't. Some services simply retrieve 
statically, some other perform complex tasks. Some services don't need 
activation semantics, some others do.

As much I always thought that "web services" always existed (in fact, 
one of the first "web service" integrators was built with cocoon! even 
before SOAP came along!), this "web 2.0" always existed, including all 
those fancy DHTML things.

I've seen a web site that used flash with interactive XML 
upload/download powered by Cocoon years ago. It was uber-cool 
graphically, it was also a nightmare to maintain, didn't play well with 
search engines, didn't perform well in usability tests and so on.

As we know very well, bleeding edges have a price: we bet on XML as the 
"data syntax" of the web and, guess what?, it happened.

Moving forward

This project became successful and the people around it with it. We got 
jobs, projects, customers, deadlines. We were on a path and we kept 
going. Things were patched and hacked to make it work, complexity grew 
and our component model made it so easy to add things that we forgot 
when it really made sense and when it didn't.

I also lost interest in it. I saw it finished. Uninteresting from a 
research point of view, so I moved on.

Recently, I started designing a new web application/publishing framework 
for RDF.... and guess what? I kept coming back wanting cocoon features 
or things that we implemented or designed or planned, even things I had 
been against for years.

One for all, I love the sitemap and I love pipelines. I love the "lego 
feeling" and the 80/20 paradigm: you get 80% from pre-built (and 
community polished!!!) components and 20% from your own programming 
glue. The cost of maintenance of your webapp is now 70% less! (20% on 
your stuff, 10% community tax). Much better than 100%.

I also love the RAD features of avoiding to compile stuff. But I also 
love that eclipse is my syntax co-pilot. I like the concept of 
continuations although I ended up using it when it was not really 
necessary and in situations where the parties that participate to the 
web service are more than two, saving that much state without the 
ability to move it across servers will hurt more than help.

Technically, I think Sylvain hit the nail on the head, even if I 
personally believe that, no matter what, we'll need a real block system, 
even if we implement everything he said.

Cocoon's biggest pain is deployment/build system. I'm with Daniel that 
solving that would make a lot of issues go away.

But I also agree with others when they say that having a "naked core" 
that needs 12Mb of jars is a little off beat.

The baby and the bath water

Cocoon is big and complex. In some parts over-designed, in others 
over-configurable, but if you want to aim at replacing Struts or PHP or 
RoR for web sites that are small in complexity and in the number of 
people that work on it, forget it, you are barking at the wrong tree. 
Leave, go away, get lost, ciao ciao, au revoir, this is not the place 
for you.

Cocoon is a framework that enables Separation of Concerns. It makes 
sense *only* when the sites are complex and diversified (or if you know 
it already, so the learning curve is gone and you start much higher!) If 

This is because separating concerns changes the slope of the energy 
distribution. Something like

  total cost of ownership
    |              o
    |             o
    |            o
    |           o
    |         o
    |       o
    |   o

becomes something like this

  total cost of ownership
    |                   o
    |            o
    |       o
    |    o
    |  o
    | o

As you can see, the total cost of ownership of a SoC-oriented solution 
will *ALWAYS* be higher for web sites that have small complexity and 
complexity that it's unlikely to change over time (blogs are the perfect 
example of web applications with small social and technical complexity 
and complexity that is unlikely to change over time).

The above was the main reason why cocoon started: I knew that servlets 
(and JSPs) had the above cost/complexity shape, I wanted something else, 
that could scale to much more complex systems.

[I still need a lot more research to show this is really the case, but 
there have been on this list several examples that show how it is true 
that cocoon enables cost/complexity distributions that feel like that.. 
here apply your own insights]

Now, those functions have, at the very least one degree of freedom (not 
two, since a web application of zero complexity, the null web 
application, has obviously zero cost): this being the slope of the function.

[there are much more second order effects, but for simplicity, I'll 
stick to the first one]

As another example, look at this chart:

  total cost of ownership
    |     *         o
    |              o
    |             o
    |    *      o         #
    |         o         #
    |  *    o       #
    | * o  #

These are three different technologies, both without SoC in mind, but 
with different complexity/cost slopes:

  * -> CGI-BIN in C
  o -> PHP
  # -> Ruby on Rails

Now, as you can see, with the same cost, you can get web applications 
that are way more complex, or, on the other hand, with the same 
complexity, it can cost you a lot more.

What it *DOES NOT* change (and I have never heard anybody claiming the 
opposite!), is the fact that the increase of cost is *MORE THAN LINEAR* 
with the increase of complexity!

As you all know, a web application/service/site has a natural tendency 
to grow in complexity, especially if successful and has the natural 
tendency to grow a lot faster than expected.

It's *at that point* that you want a technology that allows your cost to 
grow sub-linear, or, at worst, linear with the complexity increase.

But given that such functions have a degree of freedom, what about the 
SoC ones? Well, they do too. In fact, we could hope to have something 
like this:

  total cost of ownership
    |                   o
    |            o
    |       o
    |    o                 *
    |  o        *
    | o  *

why? well, because we were in this situation:

  total cost of ownership
    |           *       o
    |            o
    |       o  *|
    |    o      |
    |  o     *  |
    | o    *    |
    |o   *      |
                x      complexity

where "x" is the "equi-cost" point that separates the solutions in two 
complexity classes, so for projects with less complexity than "x" it 
made sense to use technology "*" while for more complexity than "x" it 
made sense to use technology "o"

if technology changes and the slope of the "*" technology changes, you 
find yourself with an "x" cut off that is "way" moved to the right, 
meaning that there are a lot more solutions where technology "o" doesn't 
seem appealing anymore.

  total cost of ownership
    |                  o
    |            o    *|
    |       o          |
    |    o          *  |
    |  o          *    |
    | o         *      |
    |o      *          |
                x1     x2   complexity

so now we have all sites of complexity between x1 and x2 that now find 
technology "*" to be more appealing than technology "o".

Now, as you can see from the chart, while costs are reduced for a 
solution which complexity is fixed and never changes, this is almost 
never the case and complexity has a natural (thermodynamical?) tendency 
to grow over time.

At the same time, the more the equi-cost point moves to the right, the 
harder it is to sell the technology, even if 10 years down the road, the 
total cost of ownership would be a lot less.

Microsoft became what it is by leveraging this specific psychological 
barrier. My gut feeling is that web 2.0 technologies are doing exactly 
the same and the frustration that it's perceived all around (and 
google's overhyped stock value) is another sign of this.

What can we do?

Two things:

  1) breath and relax, we are not going to get run over: changing the 
slope does *NOT* change the nature of the function (they will understand 
that as soon as they cross that equi-cost point... and complexity grows 
even faster the more "web 2.0"-ish you become, because there are more 
and more variables that you don't control that get in the mix)

  2) reduce the cost/complexity function of our technology and move the 
equi-cost point to the left

                                - o -

I've heard a lot of nonsense on this list lately. People asking polls on 
technologies, people telling users we don't need their input, people 
saying that paying community taxes is a waste, people saying that we 
should compete with Struts, people that say we need to rewrite in Ruby, 
people that believe what we did so far is all bloated and crap, people 
that mentioned the even the name has no value.

To all these people, I say: consider leaving, this might not be the 
place for you. You might have outgrown cocoon, or cocoon might have 
outgrown you.

Cocoon is, by design, attacking the part of the cost/complexity chart 
that goes past that equi-cost point: every new technology in the non-SoC 
space that lowers that cost would force us to reduce ours. If you are 
not ready for nor willing to do this dance, leave, it's better for you 
and it's better for those who stay.

If you want something on the left side of the equi-cost mark, cocoon is 
not for you. But remember, the complexity of the solution when you start 
is *NOT* going to be the same of when you finish, or, worse, of when 
your customer wants the next cool feature. You have been warned.

For those who stay, and I honestly don't care about who does and who 
doesn't, because it's not about quantity but quality, there is a lot of 
work to do.

I'll leave you some room to think about it.

No, really, think about it, there is so much cool technology out there 
and cocoon to you probably feels old, bloated and jurassic, a dinosaur 
right after the meteor stroke.

Ok, glad you made it. From now on, only constructive and respectful 
criticism will be allowed, I will specifically ignore everything else.

What vs. How

Sylvain proposed a series of technical features that cocoon is missing 
and that might make sense to have. I see this as the direction of 
reducing the slope of the complexity/cost function. And for the "what" I 
perfectly agree it's something we need. Discussing details before there 
is some code, it's completely useless.

Others, including myself, believe that a better build and deployment 
mechanism, also supporting a polymorphic and inheritable component model 
for web applications, will further reduce the slope of the 
cost/complexity function, by virtue of enabling and more granular 80/20 
paradims: where 80% is obtained by off-the shelf components, and 20 by 
tuning. Dynamic languages do, in fact, a very similar thing but at a 
much smaller granular level.

But again, if it doesn't happen, it's probably because we don't really 
need it.

Some believe that rewriting (revolution) is the way to go.

Others believe that incremental development (evolution) is the way to go.

I honestly can't tell. I learned the hard way that rewriting take always 
more energy that you expected, because the 90% of the cost in in 10% of 
the code, but you don't know which one that 10% is. So, I'm not going to 
be the one that rewrites anything anymore, but I won't stop those who 
are foolish enough to think they can.

But the ASF contains the "rules for revolutionaries". This states that 
every committer is allowed to propose an 'internal fork' but there a few 
things that it's not supposed to do, the most important being, use the 
name of the same project.

So, if Sylvain wants to start an internal fork, he can and nobody can 
stop him, but he has to pick a "codename" that has nothing to do with 
cocoon and cannot release it to the public (as distribution) before the 
cocoon PMC allows that to happen.

So, no Raccoon and no Cocoon NG and no Cocoon 3.0, those are not 
allowed, the reason being that there is *ONE* production branch of 
cocoon (2.1.x) and *ONE* development branch of cocoon (trunk), at any 
given time. Anything else is something else, a prototype, an example, a 
trial, a phase, a joke, an attempt: there is absolutely no warranty that 
it will ever work or it will ever become the next cocoon trunk.

I think Sylvain did a very valuable and deep technical analysis of the 
defects and the issues that make cocoon what it is and how we can 
improve it to make it more appealing. The "what".

But I think he did a *terrible* job on showing us how to get there. The 

I wanted to shake a tree to remove dead branches, Sylvain came with a 
chainsaw and a seed: don't know about you, but I don't have the energy 
to sit there and stare at another seed growing for years until it bares 

                               - o -

Cocoon is what it is today, but what it is tomorrow is defined by what 
we, collectively, decide.

And decisions are *NOT* made with silly polls and mile-long threads that 
evocate more frustration than intelligence. Decisions are made by those 
who code and those who are willing to back up their words with their 

And even those who want to back up their words with their actions needs 
to understand what is the best way to achieve their goal without 
disrupting everybody else's work and without lacking respect for those 
who don't share the same architectural visions.


View raw message