Prologue
--------
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
high.
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
not, *DON'T USE IT*, *USE SOMETHING ELSE*.
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
+---------------------->
complexity
becomes something like this
total cost of ownership
^
| o
| o
| o
| o
| o
| o
|o
+---------------------->
complexity
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 #
+---------------------->
complexity
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 *
|o*
+---------------------->
complexity
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
"how".
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
fruits.
- 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
actions.
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.
--
Stefano.
