On Friday, Jul 25, 2003, at 11:44 Europe/Rome, [EMAIL PROTECTED] wrote:
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 :-)
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).
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.
Now, Guido is right on the money here: how would you like to tell your boss that he/she can edit date into the relational database directly from excel? (well, maybe you don't want him/her to do that because he/she might screw up, but that's another issue)
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 does *NOT* have to be the case. mod_dav and subversion are just two of the potential webdav applications.
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.
Well, this is a quick and dirty RT that should have been discussed later, but hey, it's Guido's fault and I don't want to see quick and dirty hacks to the sitemap when more design is necessary ;-)
-- Stefano.
