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 leo.sutic@gmail.com designates
 66.249.82.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=FSOT+hbvsezhvyyGIw67wM88XmNNYJwwcW+Y0jJHE0VHrsU0ohp5LE9L0SwyvcCVlh0je1A7/3mTYZWUQ1N52+Rwynu0/T0VIDDIjW0uPDPfx/8JyJ/vo0zA9xK6EbTze/c+PE0IYwgYFzZ8LO9qIeIV7ZEXEW7Ke4F0ygcbCm4=
Message-ID: <f41e0a050512100302i4598e2d2y8726a377b3129e2c@mail.gmail.com>
Date: Sat, 10 Dec 2005 12:02:54 +0100
From: Leo Sutic <leo.sutic@inspireinfrastructure.com>
Sender: leo.sutic@gmail.com
To: dev@cocoon.apache.org
Subject: [FFT] Kitchen Sink
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I pretty much agrees with what Berin has been saying - and I also
agree with Stefano.

Berin is right in that we must strive for simplicity.
Stefano is right in that a (somewhat) complex system is required to
solve even more complex problems.

The problem with Cocoon as I see it is this:

Think about Java. It is a fairly simple language, right? You can do a
"Hello World" pretty easily. But you can also do some fairly complex
things with it.

The thing is this: You don't need to know the internal workings of the
JRE or compiler in order to do this. You are abstracted away from it.
Sometimes you have to look a thing or two up, but then you're doing
some pretty advanced stuff.

Cocoon lacks this abstraction. You need to know about its internals to
do even basic stuff.

If I can write both a blog and Cocoon in Java, why can't I use Cocoon
for writing a blog? Why this "that problem is too simple for Cocoon."
Maybe it is, but is that the problem's fault?


So what's my recipe for success? Get that abstraction in place. Cocoon
should be *a language for writing web apps*. Now we have XML, XSL,
Javaflow, JSFlow, and a host of other languages. What if Java wasn't
one language, but you had to write a JCL file to go with you java
Hello World, a bunch of headers, and so on.

That language can then be modularized so that it can be extended, or
so that parts of it can be reused - but I think the facade that has to
be presented to the user has to be focused on one thing, and the user
shouldn't have to look behind it (in 99.9% of the cases).


package sample;

@website
class MyHomepage {

    // Set by runtime execution environment.
    @dependency
    protected Translator translator;

    @uri ({"/", "/index.html"})
    public Response mainPage () {
        return new StreamResponse (new File ("index.html"));
    }

    @uri ({"/hello"})
    @pipeline (MyLookAndFeel)
    public Response helloWorld (String who, String language) {
        // Must be called /hello?who=3D...&language=3D...
        return new StringResponse (
            translator.translate ("Hello " + who + "!", language));
    }
}

@pipeline
class MyLookAndFeel {
    ...
}

I skip things like "how do you use XSL" and so on - I'm making this up
as I type, and it will take months to architect a proper language.

I see the system as having two parts:

1. A language for writing webapps. It can (should perhaps) be java
with annotations or other facility for extending it.

2. An *embeddable* execution environment that will run webapps written
in (1). This ***must*** be decoupled from any specific servlet
container, and should not try to be an app server in itself. For
example - class loading should not go here.


By having this one language, writing tools for it is simpler. If an
AST parser is provided for tool writers, it is even easier, and
anything you can do in XSL with the current XML sitemap or xsp or ...
can be done. You can also have code generators for websites.


I think this is what Cocoon has been evolving toward, and a lot of the
pain is that the problem ("make up a language for webapps") is just so
*hard*. Cocoon has gone from XSP to Logic Sheets (which I never
understood) to XSL to JavaFlow to... We have tried to create the one
language for the web, but done so incrementally and under pressure to
deploy. "Let's take C. Let's add some macros... let's add some more
macros..."

Stefano also noted that there is a whole lot of talk and not much code
being hammered out. True. In no way am I demanding that you develop
the above. I might write it myself, given time. See this as just food
for thought.

Anyway, my two cents.

/LS