cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Is Cocoon Obsolete?
Date Sun, 23 Oct 2005 17:39:28 GMT
Peter,

thanks so much for this, great plug for me to start.


Peter Hunsberger wrote:
> On 9/30/05, Stefano Mazzocchi <stefano@apache.org> wrote:
> 
> There was a moment where I could have been one of the first people to
> respond to this thread, you just happened to ask this question when I
> was watching the Cocoon mailing list for some reason or other. 
> However, in spite of the fact I've been debating whether we could run
> our software without Cocoon for the last 6 months or so I honestly
> didn't know how to answer your central issue: what's next?
> 
> I've got a gut feeling for what we need, some of it resonates with
> what you post here, but I've personally grown sort of attached to
> Cocoon, so first off, I'd have to answer the subject line with a
> resounding "no".

:-)

Well, I never really expected people on this list to say "yeah, it's 
crap, I moved on" because those who did, would not be here to read that 
message anyway.

The real question is: does the cocoon community realize that the 
tectonic plates of web technologies are shifting and that we might find 
ourselves in a completely new environment really soon? And if so, do we 
understand it? do we defend our positions or we attack?

Read my comments below.

> <snip/>
> 
>>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?
>>
> 
> Define advanced?  For the foreseeable future we need:
> 
> 1) low cost, robust, legacy system interfaces (canonical form is
> cheap, distributed clients don't lend themselves to canonical form);
> 
> 2) high speed, 100% dependable, atomic, global, data transaction
> management through to the persistence layer (clients != dependable);
> 
> 3) back end security (in addition to client authentication).
> 
> I'm sure there are others, but no, I still think we need good solid
> server side capabilities.

One thing that turns me off about cocoon *today* is the pretty steep 
*perceived* learning curve.

If packaged correctly, a naked (no blocks!) cocoon would take no more 
than an improved Bertrand's SuperSonic Tour. We are getting there. 
Slowly, painfully, and dragging our userbase with us without abrupt 
transitions... maybe too slow, I don't know. But I knok that revolutions 
are hard to manage, so I'm not unhappy about the way we are dealing with 
day to day evolution.

But I think we collective lack a vision for what's coming up next and I 
feel this as a weakness.

> Perhaps it's just that you started out mostly server side and now
> you're discovering that the client is "fun"? (And that advanced
> clients are even more fun.)

I did that with Linotype... which had more code in javascript than in 
XSLT... and it felt like a "good thing"(tm).

Between Moz and Cocoon, both have similar problems, good visions and 
architecturs, but they are hard to explain because novices don't hit 
those walls until really late in the game.

The climb is very steep but the plateau up there very flat and very 
high. We need to build a way to get people up there quick. Ruby on Rails 
wrote wizards, we have eclipse plugins (sort-a).

We need to do more in that space and we are. It's great.

But both moz and cocoon face a similar problem: how are they going to 
face a future of radical changes around them? The web ecosystem is very 
solid and inertial, yet completely non-linear, things like del.icio.us 
are small butterflies that trigger hurricanes somewhere else.

Is there anything we can do to watch what's happening and draw 
conclusions on what we need to prepare for? or enable? or avoid? or 
deprecate? or influence? or push? or polish? or remove?

We are moving forward in many directions:

  1) real blocks
  2) build system
  3) binary distributions
  4) CMS for docs
  5) IDE (with Lepido)
  6) rail-ification and wizards
  7) solidification
  8) separation and identification of current and legacy features

which are all great, but is that enough?

> <snip/>
> 
>>But as a researcher, a scientist and one that likes to push the edge, I
>>sense that cocoon is kinda 'done', not as in "finished, passe'", but
>>more as in "been there, done that".
> 
> Sure, that makes sense.  But, give it a couple of years: there are
> many fundamental capability enabling patterns embodied in Cocoon
> (whew):
> 
> - ack-nak/controller-response
> 
> - translation/transformation
> 
> - iterative processing of small increments of work (the true
> separation of concerns)
> 
> none of these are going to go away.  In 10 or so years you'll be
> wondering "did I really understand what I was doing and/or thinking
> "h*ly shit that's coooool...."

This is correct.

> Cocoon should never be done. IMO, the two big problems of generalized
> graph traversal and graph merge/update will always require some
> capability to handle orthogonal concerns at run time because pure REST
> can't map the entire universe. There are always ambiguities remaining
> to be discovered that can't be named/identified (pick concept de-jure)
> before hand.

Here we go, closing in...

> I want to processes the work on the hard problems on the server if
> only so that I can use general consensus on whether any new discovery
> means anything or not. I want a way to life cycle the merged opinions
> and discovery at a central location so that someone can review the
> results for longitudinal and retrospective discovery.  I want a way to
> know when more than one person has a need to work on the same problem.
> I want way more, but enough ranting for now...

The great thing about such an outstanding and alive community is that 
you have many objective judges doing the sort of darwinian selection of 
ideas right away. In the academic world, unfortunately, peer review is 
done by no more than 3/4 people... and all of them normally savy but old 
and established, with clear interests and agendas. Here it's a much 
bigger audience with a much more diverse set of agendas.

Then you have the open source model that selects the ideas that look 
good on paper but that require more energy than they seem to be 
worth.... this filtering does *NOT* happen in closed environments where 
ideas that pass the first phase are pretty much always implemented 
(unless the developers fail to do so).

The mix of those two things is radically different than in the two 
environments. I am applying open source principles to the academic 
community and resulting in incredible disruption: they can't figure out 
how we can be so fast in doing things.

Fast enough to find cocoon slowing us down (not the code, but the 
technological status)

Therefore the scratching my head that brought this thread.

> IOW, the life of the researcher (in an institution) should not only
> involve client interaction but institutional management of the process
> for the researcher via some server that can merge and transform all of
> the ongoing interactions so that all can benefit. (key words: merge
> and transform)

Agreed.

>>Sure, lots of things to polish and little things to continue to improve,
>>but I wonder if the action is somewhere else.
>>
>>How do you feel about this?
> 
> What we really need?
> 
>   - back end legacy connectors.  I can do that with JBoss;
> 
> - 100% 24/7 rock solid transaction management and data persistence.  I
> can do that with JBoss and some commercial (or maybe even OS) RDB;
> 
> - flexible data translation and extraction.  I can do that with Saxon;
> 
> - involving, low error, client side interaction: I can do that with
> AJAX and the rest of the browser stuff that you mention.
> 
> So why do I want Cocoon (Java or similar glue is assumed)?  Because I
> still need some sort of bridge from the first three things to the
> last.  

Correct. We ended up writing our own... and it was no more than 50Kb of 
java code. Since for us size matters, cocoon was not able to replace 
that with such little space... but others were the turn offs... the fact 
that RDF and XML have a serious impedence mismatch.

I have been tasked to find a solution for this problem and now I think I 
have found one.

> I need a really efficient action dispatcher. In spite of the
> fact that many  might feel that this is one of the weakest parts of
> Cocoon, this is what it does better than anything else:
> 
> client action -> map to handler -> run business rules -> persist
> results -> (begin again)
> 
> Eventually, I expect some form of generalized Ontology traversal
> (perhaps the semantic Web) to handle the second step

yeah, people will push for that, but I doubt declarative inferenced 
processing will ever be as predictable as explicit procedures.

> but darned if I
> see any real AI stepping up to handle the third step.  

:-) [even if I'm sure many startups will try to that... and fail ;-)]

> For the
> foreseeable future I need some kind of multi-technology mosh pit for
> that process to work in and currently that looks a lot like Cocoon.

I know. It looks "a lot like" but it's not that.... and I want to bridge 
the two.

> So
> that tells us where the real work is: object mapping, pattern
> recognition, etc (and the great bugbear; distributed cache management
> to keep the results fresh but yet responsive).

Hmmm, not sure.

> The client is starting to be able to talk to the humans, next we need
> a way for the server to truly understand what that interaction means,
> requires, and implies in a global sense.

Not only, but don't worry, I'll come up with something here soon.

-- 
Stefano.


Mime
View raw message