Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of peter.hunsberger@gmail.com
 designates 64.233.184.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BfZqCizEVUTX5f+gCl38S12Lsk8mo64NPyUZuHwGoFV7Z9O6hiV1aA9678qpfstboPKpxSPUlD44RNoGZwcA3Vkphn34dRy5F3iO+p7vJ/f86RRnZ5esE2nsOxq96Cn8B6YGX71SApGMiq3hwlC8Uj1BJi/ghNsP0e6GLt3NS9c=
Message-ID: <cc159a4a0510212212p1d0aac2au1e7276521058bc43@mail.gmail.com>
Date: Sat, 22 Oct 2005 00:12:39 -0500
From: Peter Hunsberger <peter.hunsberger@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: [RT] Is Cocoon Obsolete?
In-Reply-To: <433DB4B5.8070703@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <433DB4B5.8070703@apache.org>

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.=20
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".

<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 !=3D 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.

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.)

<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...."

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.

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...

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)

<snip/>

> 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.  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, but darned if I
see any real AI stepping up to handle the third step.  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. 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).

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.

--
Peter Hunsberger