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
hm, do we really need to look at it as symmetric?
No, we don't. I've been thinking about this a lot and I think that symmetry is not only a holy grail, but it's the wrong grail to consider holy. Read on.
I know we are tempted to do so, but is it a must?
It is tempting, but symmetry-driven design is bad. we must understand what we want, why and what is limiting us.
I knew that I would have triggered this comment. However, let me just state that not everything that contains "simmetry" in inherently bad: in most case I'm totally with you, but there are situations where you need simmetry, and WebDAV looks to me (potentially) as one of those.
I see that you don't particularily like the "web folders" metaphore, and I'm with you when you say that this is just one of the possible DAV applications, yet it's quite an important one. However, thinking more about it, it might be cool to d&d an SVG and see an XSL popping out: but the idea of exposing the wonderful world of Cocoon as a disk is too exciting to me to be left behind. :-)
Note that on a real FS, everybody knows the difference between
/home/blah/news
and
/home/blah/news/
because the OS enforces type checking on these (on a POSIX file system you cannot open a directory for writing as a file, for example).
I don't see it. Actually /home/blah/news is a directory even if you don't put a trailing slash on it, and you can't have a file and a directory sharing the same name. But this is nitpicking.
If I have a resource like
http://blah.com/news/
and I want to edit, I could ask for
http://blah.com:8888/news/ http://edit.blah.com/news/ http://blah.com/news/?view="edit";
Well... yes and no: in a shared folders scenario this doesn't apply. And this is *exactly*, besides, where Cocoon might shine when compared to Zope: Zope supports WebDAV, but what you see from your shared folders are the "bare" zope components, with little or no way (AFAIK) to expose an aggregation or trasformation of both. Cocoon, instead, could offer a particular "view" to editors which is vitual and assembled on the fly for each particular request.
The real problem is what's Nirvana for each of us: to me it would be just great to have a way of automatically expose a Cocoon pipeline both as an HTTP resource *and* as a DAV (editable) resource. Something like:
<map:pipeline dav="on">
This might implemented, as a default, in the Zope way (giving access to the bare resources) or, if overridden, in a custom way (filtering, aggregating and manipulating resources, as an example). But this requires simmetry to happen, so I guess it will remain just a dream.
In your scenario, OTOH, there should be a particular sitemap configuration for each pipeline, which means that one will need to provide for every webdav exposed resource a particular configuration: see Guido's great example, it's really cool but it's also a PITA if you are to apply it in a more general way.
I normally prefer the virtual-host approach. something like this
[frontend] <- [repository] <- [backend] http://blah.com http://edit.blah.com
where frontend and backend are separated (frontend might even be a static representation of the saved content (say, created by a cronned forrest every hour or so).
The above setup removes you from the need from having to be symmetric.
This is yet another approach: a different Cocoon with a different configuration. Feasible, but then again possibly unmaintainable since it requires to keep in sync two different pipeline *logics*.
(they want to put back where they got I assume?)
actually if you look at the combination of matchers/request-method-selector you wrote up it more looks like the request-method being part of the uri-request space almost?
I dislike this. the action should not be encoded in the URI space.
Definitely.
2) direction: Cocoon is clearly designed for an "inside-out" type of flow in mind, while WebDAV is fully bidirectional.
this is not true anymore. with the ability to have pipeline dump their content on an outputstream if called from the flow, cocoon reached complete bydirectionality.
I disagree here. Cocoon is bidirectional *if* flow is used, which is a serious limitation. Actually I've been struck by this lately, on a presentation engine we are building, and I see a possible solution (but it deserves an RT on its own).
Design-wise it's difficult to adapt the G-T-S pattern to an incoming stream of data,
I can't see why. Admittedly, there are generators who are hardly reusable in both in-out and out-in case (StreamGenerator or RequestGenerator, for example) but that is not a deficiency of the pipeline design, expecially now that the output stream of the pipeline is reconnectable.
OK, maybe "design-wise" is wrong. What about "semantically" instead?
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 stuff sounds like flow integration on a separate section of the uri-request-space?
I totally agree. i think it would be fairly easy to implement a full dav stack with flowscript and a few java components that wrap around a repository (could be as simple as a file system)
Then again, you're not talking about integrating WebDAV into Cocoon, but just give some hooks (something that can be done pretty much now already) to make webdavapps using flow. Now, while flow surely rocks, I feel that WebDAV support, as an HTTP extension, should be reflected in the sitemap too.
I think we should get this release out of the door ASAP, then start thinking about what's next.
I just wanted to tell you that there is a lot of thinking to do about webdav but we are in pretty good shape with what we have.
+1
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
