Return-Path: 
 <dev-return-45365-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 46981 invoked by uid 500); 25 Jul 2003 15:08:41 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 46958 invoked from network); 25 Jul 2003 15:08:40 -0000
Received: from dobit2.ugent.be (HELO dobit2.rug.ac.be) (157.193.42.8)
  by daedalus.apache.org with SMTP; 25 Jul 2003 15:08:40 -0000
Received: from allserv.UGent.be (allserv.ugent.be [157.193.40.42])
	by dobit2.rug.ac.be (8.12.8/8.12.8) with ESMTP id h6PF8gFY017269
	for <dev@cocoon.apache.org>; Fri, 25 Jul 2003 17:08:42 +0200 (MEST)
Received: from otsrv1.iic.rug.ac.be (otsrv1.iic.ugent.be [157.193.121.51])
	by allserv.UGent.be (8.12.8/8.12.8) with ESMTP id h6PF8fxR008060
	for <dev@cocoon.apache.org>; Fri, 25 Jul 2003 17:08:41 +0200 (MEST)
Received: from outerthought.org (host113 [192.168.123.113])
	by otsrv1.iic.rug.ac.be (8.11.6/8.11.6) with ESMTP id h6PF8gx08979
	for <dev@cocoon.apache.org>; Fri, 25 Jul 2003 17:08:42 +0200
Message-ID: <3F2147F9.6050203@outerthought.org>
Date: Fri, 25 Jul 2003 17:08:41 +0200
From: Marc Portier <mpo@outerthought.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en, nl-be
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Webdavapps with Cocoon
References: <8AD31F59-BE8C-11D7-8B25-000393D2CB02@apache.org>
 <3F211E9F.9030908@apache.org>
In-Reply-To: <3F211E9F.9030908@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
> 

<snip />

> 
> Now Cocoon, in its present incarnation, is heavily biased by the 
> "read-only" syndrome, and this makes IMO very hard to enter the WebDAV 
> world. I see two serious areas where WebDAV support needs careful 
> (re)thinking of core Cocoon patterns:
> 

I think this applies also to more classic file-upload schemes?

> 1) URI space decoupling being unreversable: while this is a *major* 
> feature of Cocoon (and something that might help immensely when applied 
> to a DAV environment: views on WebDAV would really kick ass, imagine 
> presenting your XML files as virtual OpenOffice .sxw that are assembled 
> /disassembled on the fly), the drawback is that, in most cases, it's 
> impossible to work your way from the pipeline result to the single 
> pieces that make that result happen. Even the simplest XSLT 
> transformation can't be reversely applied, so now there is no way to 
> understand how an resource should be treated in a symmetric way when 
> requested or uploaded. Oh yes, you can
> 

hm, do we really need to look at it as symmetric?
I know we are tempted to do so, but is it a must?
Is it imposed by current webdav enabled editors?
(they want to put back where they got I assume?)

actually if you look at the combination of 
matchers/request-method-selector you wrote up it more looks like 
the request-method being part of the uri-request space almost?

or put differently each request-method caters for a separate uri 
space?  taking from there the symmetry between those spaces is 
something you can or cannot want to achieve?

(we're not used to look at this in this way, and I might be 
totally off scale here)

> <match pattern="*.xls">
>   <select type="request-method">
>     <when test="GET">
>        <generate src="{1}.xml"/>
>        <transform src="xml2poi.xls"/>
>        <serialize type="hssf"/>
>     </when>
>     <when test="PUT">
>        <generate type="xls2poi"/>
>        <transform src="poi2sourcewrite"/>
>        <transform type="sourcewrite"/>
>        <serialize type="dummyserializer"/>
>     </when>
>     [...]
> </match>
> 
> but this, apart from being ankward, doesn't work in general for all 
> pipelines: think about aggregation at a very least.
> 

isn't this aggregate example just showing that some GET-URI's are 
to be considered as read-only? (not to be abused for a PUT that is)

couldn't dav properties (PROPFIND?) provide such meta-data per 
GET-URI?
is any usage of those properties in any way standardised?

> 2) direction: Cocoon is clearly designed for an "inside-out" type of 
> flow in mind, while WebDAV is fully bidirectional. Design-wise it's 
> difficult to adapt the G-T-S pattern to an incoming stream of data, when 
> you're barely generating stuff (you're actually deserializing it) and, 
> mostly, when you're not serializing anything but a simple response 
> (think MKCOL, MOVE, DELETE and the like).
> 

this stuff sounds like flow integration on a separate section of 
the uri-request-space?

> This said, I have no real solutions to that, but I'm very curious to 
> learn more about your "extractor" concept. I think this is something 
> needed, yes, but would that be enough?
> 
>> webdav has been thought as a protocol for saving and retrieving files, 
>> but this is, again, another file-system injected syndrome of mod_dav. It
> 
> 
> Though this makes it a tremendous tool too! The problem is that right 
> now all the WebDAV implementations are "dumb" filesystems, where all you 
> get is persistent storage. What I would love to see (and Cocoon would 
> fit just perfectly) is the ability to build around the file system 
> metaphore a whole set of components being able to react on the 
> "filesystem" operation. In this case, a "save" (or "drag 'n drop") might 

see this makes me return to the uri-binding again...
if we were to do this without webdav and only with POST and 
file-upload stuff then the uri would be holding the 'action' that 
webdav carries in his method

> mean an email sent to an administrator, or a workflow procedure being 
> started: as easy as that, no client needed, just what we already got, 
> networked shares and (maybe) a web browser: who needs a CMS client 
> anymore then? Probably only CMS administrator, not users. Or (again) 
> think about views/facets: being able to glue the Cocoon power to WebDAV 
> might mean giving different content to each user. Graphics might see 
> only images, and only in hi-rez: Cocoon will take care of making scaled 
> down versions, while hiding them from the users. Possibilities are endless.
> 

mmm, dreaming allowed...
MOVE of a product.xml-file to another productline-collection 
results in a sql update on the foreign-key relation ?

>> I would love to see cocoon becoming a framework that can glue together 
>> everything on the web, from stateless publishing from stateful webdav 
>> applications and yeah, why not, once you can do webdav applications 
>> you can do SOAP applications or XML-RPC applications, they are, more 
>> or less, all XMLoverHTTP stuff.
> 
> 
> Oh, me too, believe me! This might be the Next Big Thing (hey... wait, 
> are we ready to be 10 years ahead of the crowd? ;-)).
> 
> Now for the big question: should we leave this discussion for now, 
> focusing on the upcoming release and take webdavification as one of the 
> major challenges for the next generation (this alone might be a good 
> reason for Cocoon 3.0 IMHO), or shoud we have some more fun on the topic 
> here and now?
> 

hehe, the avalanche has already started :-)
managing the change into timing/planning and releases is a 
different aspect, they can (and should) run in parallel IMHO

the bigger challenge of being 10 years ahead is that these fast, 
wild, non-domesticated, associated thoughts here and now aren't 
mature enough to pull of anything and the discussion dries up 
before it started... we shouldn't add a management constraint 
onto that IMHO

> Ciao,
> 

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org