On Friday, Jul 25, 2003, at 11:44 Europe/Rome, [EMAIL PROTECTED] wrote:
"Europe/Rome" : Stefano is ba-a-ack !
Inspired by an email of Michael Homeijer http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103483890724049&w=2 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 cocoondev.org.
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).
<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. 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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
