cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Webdavapps with Cocoon
Date Mon, 28 Jul 2003 12:23:28 GMT
Stefano Mazzocchi wrote:

> On Friday, Jul 25, 2003, at 11:44 Europe/Rome, wrote:

"Europe/Rome" : Stefano is ba-a-ack !

>> Inspired by an email of Michael Homeijer 
>> I created a first version of a DAVmap, a sitemap serving as a WebDAV 
>> server.
>> If you extract the zip file to <cocoon-context>/samples/webdav, you 
>> can mount http://localhost:8888/samples/webdav/davmap/repo as a 
>> webfolder.
>> I tested it with Windows Explorer on win2k, with XML Spy, an 
>> application build on the Slide WebDAV client library and the 
>> WebDAVSource (yes, that means you can use Cocoon as its own WebDAV 
>> repository :-) 

Way cool, Guido !

But the bad thing about WebDAV on Windoze (aka "webfolders") is that 
it's not a real filesystem : you cannot open the file directly from 
there, but only copy/paste it on a "real" filesystem. Or did I missed 
something ?

>> As this again is based on Cocoon's source resolving you could expose 
>> your CVS repository via Sylvain's CVSSource or a Xindice Database 
>> (given someone implements TraversableSource and maybe 
>> ModifiableSource in XMLDBSource). You could even integrate some data 
>> of a SQL table or just proxy another WebDAV server (to leverage its 
>> versioning or to plugin some workflow logic). 

Quick update about the CVSSource : I did a major rewrite for one of our 
projects (Gianugo : it's a CMS using dynamically-generated sxw files to 
edit content!), and it's now an Excalibur Source and supports crawling 
the version history (only on the main branch), tagging, cache validity, 
etc. I committed this new version this morning on

What's to be done now is handling branches and move to Eclipse's CVS 
client library in order to migrate into Cocoon's CVS (it currently uses 
JCVS's client library which is LGPL'ed).


> 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.
> Now, is the sitemap ready for this?
> No, it needs a new concept. Something I've been calling "extractor": a 
> component that is able to extract information from a pipeline and make 
> it available to the sitemap for further selection of components.
> why? because both WebDAV and SOAP have the terrible attitude of 
> storing pipeline-routing information *inside* the pipeline.
> It has been proposed in the past to allow selectors to have access to 
> the pipeline, but I like the idea of "extractors" more. 

Mmmh... "extractor" or pipeline-aware selectors somewhat imply a single 
processing pipeline. Where does the flow fit in this ? What about 
handling this kind of request by a flowscript that would call an input 
pipeline (term introduced by Daniel Fagerstrom) that would extract the 
meat from the incoming stream (e.g. build a bean/hashmap/woody 
form/whatever from its content), and then call a regular response 
pipeline after having processed  the incoming data ?

In other words, streamed requests aren't so much different from regular 
requests : it's just that incoming data is more complex and that 
decoding is not handled transparently by the servlet engine. Once 
decoded, the processing model can be the same as usual.

What do you think ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message