Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of peter.hunsberger@gmail.com
 designates 64.233.184.198 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=Yxm5qgYzju/16YKnjlsH6kbuXNld9ZJoqXRFj55hNk7jbGh5Qg9ZeKsVcyE3Ic4BK1KC+AAuzGymAZZVQAktiUxqLDAtVtMDWjdE9nM1i7Ku8gQwfHl30jBWFvj15vHHPh3AC6S6Di5jh2HYgKN6byKfx3rMi/u+WMcRC2h4Jas=
Message-ID: <cc159a4a0510240805q7926f301rd1a49a05192caad@mail.gmail.com>
Date: Mon, 24 Oct 2005 10:05:35 -0500
From: Peter Hunsberger <peter.hunsberger@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: [RT] Is Cocoon Obsolete?
In-Reply-To: <435BCAD0.2080303@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>
	 <cc159a4a0510212212p1d0aac2au1e7276521058bc43@mail.gmail.com>
	 <435BCAD0.2080303@apache.org>

On 10/23/05, Stefano Mazzocchi <stefano@apache.org> wrote:
> Peter,
>
> thanks so much for this, great plug for me to start.
>

No problem, I was wired on coffee after a nice long dinner party and
unable to sleep and I had wanted to revive this thread for some
time...  Just a couple  of comments:

<snip/>

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

Yah, I know that, but even if we did move on I'd watch this list for
some time just to make sure the move really made sense and because a
lot of good ideas get discussed on this list in any case.

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

Tough stuff always has long learning curves.

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

Best practices take a long time to emerge.  They're also hard to
identify when they do emerge.  The Cocoon community probably spends
some extra resources chasing dead ends (and thus part of your point),
but over all I think there are few communities doing much better (I
don't think the scope of Ruby on Rails is large enough to qualify yet,
though it's nailed one or two best practices.)

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

Yah, I'd agree, Cocoon is big, there are a lot of competing visions involve=
d.

<snip>good client things, academic communities discussion</snip>

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

Go on....???  For us it's also got to do the security thing as part of
the "glue"...

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

Should be no difference at some point (maybe a long way out): code is
code, graphs are graphs, errors are errors.  You can code your
assumptions however you wish, but it's the unknowns that cause the
problems, not the method of coding.  Of course the other issue is
efficiency...

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

Sooooo, you've got something up your sleeve?  Do tell...

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

Ok, we won't be staring our next release cycle for at least 8 months
(we're halfway into a big one at the moment).... ;-)

--
Peter Hunsberger