cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Webdavapps with Cocoon
Date Mon, 28 Jul 2003 13:45:51 GMT

On Monday, Jul 28, 2003, at 14:23 Europe/Rome, Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:
>> On Friday, Jul 25, 2003, at 11:44 Europe/Rome, 
>> wrote:
> "Europe/Rome" : Stefano is ba-a-ack !

Yep, I'm back.

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

no, you are right, webforlders suuuuuuuuuuuuck! and they are as buggy 
as hell, expecially if you do webdav over https with digital 
certificates. forget it, you have to use a commercial application 
(don't remember its name).

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

maybe if you give us some pointers on what needs to be done, somebody 
might chime in.

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

not at all, actually, the opposite.

> Where does the flow fit in this ?

just like any other pipeline.

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

sure, but will be up to you do decide how to write your webdavapp. 
that's the point: cocoon should provide you the low level components 
and you compose them as you like.

Today, cocoon cannot select parts of a pipeline depending on 
information contained inside the pipeline itself.

So far, we didn't miss this much because selection is never done with 
data that passes inside the pipeline, but all xml-rpc-like applications 
(and SOAP and WebDAV fall into this category), the information for 
processing the request has to be *extracted* from the pipeline flow 
before being made available.

Note that I said "processing the request" and this impact all matching 
selecting and flow control.

Do we really need extractors? no, we can extend the StreamGenerator 
into a WebDAV StreamGenerator that extracts information from the stream 
and places it into the request parameters, then you can do processing 
as it was a normal request.

But just as the aggregator is just a special generator, I was thinking 
of introducing the concept of an extractor which is just a generator 
but that expects serious payloads that contain inforamation that might 
be needed by the sitemap/flow to process the request (NOTE: both the 
sitemap and flow DO NOT have access to the pipeline content directly, 
and this should *NOT* change! this is the reason why we should 
introduce this 'extraction' concept)

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

Hmmm, hmmmm, hmmmm, you are triggering second order thinking.... 
hmmmm... I need a whiteboard... I'll be back soon.


View raw message