Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Date: Wed, 7 Mar 2001 22:26:48 +0100 (MET)
From: Uli Mayring <ulim@denic.de>
To: cocoon-users@xml.apache.org
Subject: Re: stability of 1.8.3-dev?
In-Reply-To: <Pine.LNX.4.30.0103071357530.7785-100000@rdu25-4-159>
Message-ID: <Pine.GSO.4.10.10103072138450.26595-100000@denics7.denic.de>
"X-Ncc-RegID: de.denic"
MIME-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.4 |June 8,
 2000) at 07.03.2001
 22:26:47,
	Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 07.03.2001
 22:26:50,
	Serialize complete at 07.03.2001 22:26:50
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

On Wed, 7 Mar 2001, Donald Ball wrote:

> actions do return maps.

What is a map?

> > I thought the whole point of XML was to standardize communication and
> > interfaces?
> 
> yeah, sure, but it's not appropriate for _all_ communication. surely you
> wouldn't assert that all java methods should use XML to receive their
> paramters and return data? especially in a SAX environment! :)

Well, the point where you overdo it is open to debate. In Germany we have
a saying that roughly translates to "egg-laying woolmilkpig". This is an
animal that does it all, it's only drawback being that it doesn't
actually exist.

So, XML is a bit like this animal, if you listen to different people and
combine their intended or actual usage of XML, you'll end up with an
egg-laying woolmilkpig. So, where to draw the line?

First, it seems we Cocooners are booked into Java big time, so we might as
well use Java's interfaces and communication mechanisms on the low level.
It doesn't make any sense to wrap this in XML. The scope of Java is
basically a JVM, so if we want to reach out over the boundaries of a JVM
we need something else. SOAP comes to mind, as does XML-RPC and a number
of other techniques, but this is IMHO the job of the application writer,
not of the Cocoon developers.

XSP, on the other hand, lies somewhere in between that. It's basically
Java code with an XML wrapper, so non-Java people can use it to build
sites and Java-people have a sane way of deploying logic on the Web. So
from that point of view it makes sense to introduce an additional
mechanism.

Now, from what perspective does it make sense to introduce yet another
mechanism? The answer in the case of the sitemap is something like: "XSP
can't work on such a low level. We'd rather be writing specific and
efficient code for a particular task (request handling) than going
overkill devising a general mechanism."

So, what is the answer in the case of actions? Are they like the sitemap a
very specific solution for a particular task?

Will we be able to solve a large problem (web-application design) by
dividing it into smaller tasks and writing efficient, but incompatible
code for each of these tasks?

My experiences are that XSP scales extremely well into large projects,
whereas XSL doesn't. So, in my mind, time spent on XSL will have far
greater leverage on web applications than time spent on fixing XSP.

So, it will be interesting to see how Cocoon2 with its "bits'n'pieces" 
approach plays out in the long run. But I think we'll know before by just
looking at how elegantly it integrates into Avalon. How many blocks will
Cocoon2 consist of? :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung