cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] Webdavapps with Cocoon
Date Fri, 25 Jul 2003 12:12:15 GMT
Stefano Mazzocchi wrote:

> aaaaaaaaaahhhhhhhhh, I hate it when people spoil my yet-to-be-released 
> RT :-(
> I was holding an RT on "what is missing to the sitemap to *really* kick 
> ass" waiting for 2.1 to be released final and one of the key points was 
> to make it easier to write "webdavapps" in short "webapps" with DAV 
> support.
> Many people think of WebDAV as a protocol. I prefer to think of it as 
> HTTP++. And web applications are made on top of HTTP, webdav 
> applications should be made on top of HTTP++. It's as simple as that.

This looks indeed as a simple picture but (see below for more) it 
requires some good rethinking of our mental schemes after 10+ year of 
HTTP based development (gosh, a few days ago I downloaded the 10 years 
old version of Mosaic... ah, memories!). The HTTP world is mostly 
monodirectional, with just occasional bidirectional support which was, 
however, intended as a way of passing parameters rather than write data: 
  POST being used actually as an alternative to GET makes that clear 
enough. Actually it's striking to see that PUT was there since the first 
versions and nobody cared that much, but I'll leave that for future 
ramblings. :-)

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:

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

<match pattern="*.xls">
   <select type="request-method">
     <when test="GET">
        <generate src="{1}.xml"/>
        <transform src="xml2poi.xls"/>
        <serialize type="hssf"/>
     <when test="PUT">
        <generate type="xls2poi"/>
        <transform src="poi2sourcewrite"/>
        <transform type="sourcewrite"/>
        <serialize type="dummyserializer"/>

but this, apart from being ankward, doesn't work in general for all 
pipelines: think about aggregation at a very least.

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

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


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Now blogging at:

View raw message