On Monday, Jul 28, 2003, at 18:57 Europe/Rome, Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
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.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?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.
hehe, it's good when you start to predict where and when my anti-patterns alarm go off, it means that I infected you with them ;-)
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.
Careful here: I never said that a "symmetrical design is bad" (actually, I love when designs become symmetrical), what is bad is "symmetry-driven design".
The design should be done driven by the constraints where it must operate and it should, at the end, turn out symmetrical, or, at least, it should be possible to find a pleasant visual representation of the concept.
If not, the design is probably wrong.
Driving design with symmetry might not yield the best results because simmetry (and not adherence to environmental constraints) is used as the metric and for this reason, you don't have a final checking validation metric.
[yes, this is blatantly stolen from Einstein's 'beauty meter' design pattern on the analysis of physical theories]
That's how I do design:
1) find something that solves the problem in the current context 2) measure degree of symmetry and SoC 3) go back to 1 using results from 2 to increase the context
the problem emerges if you start using metric in step 2 before you have solved the problem: you might cut short solutions that work better later on.
This is a sort of simulated annealing with "simmetry and SoC" as the hamiltonian function, the resulting simulated crystal is the final design.
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. :-)
Again, I never said I didn't like the "web folders" metaphore. I said I didn't like the "web folders" implementation on IE which is buggy as hell. I stated that I love the fact to be able to mount a webdav server as a file system on macosx (and WinXP, Guido says, but I never used XP so I don't know)
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.
My point was: on a file system, you are not precise with a trailing slash, in some cases things don't work properly, on the web this is much less so.
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.
why not?
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.
I don't know Zope enough to say if the above is true or not, but as for offering particular views, I don't have to remind you that fat clients (webfolders and FS mounters included) don't allow you to specify what type of request parameters you want in that webdav request. This forces you to use a special URI space for your webdav folders and this is exactly what I proposed above. I really don't see why this scenerio doesn't apply. But maybe I'm missing something.
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.
I think this is mod_dav injected nirvana, but I don't see why DAV is so different to treat it in such a special way.
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.
nono, wait. I already stated that the sitemap needs further semantics to allow xml-rcp-like requests to be handled without a shitload of verbosity and cut/paste around it (as it is the case today and Guido's example shows).
Just I don't want to make this DAV specific, because that would be limiting us.
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*.
I rarely see a backend and a frontend needing to be kept in synch with sitemap description more than you would do if you had
host.com/ host.com/edit/
mounted on different subsitemaps.
Besides, you don't take into account the future where cocoon webapps will be hotdeployed. in that case, it's totally possible to create the two frontend/backend sitemaps XSLT-transforming a common sitemap that includes different metadata at block-creation time.
(they want to put back where they got I assume?)I dislike this. the action should not be encoded in the URI space.
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?
Definitely.
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.2) direction: Cocoon is clearly designed for an "inside-out" type of flow in mind, while WebDAV is fully bidirectional.
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).
You are right. Cocoon is bidirectional if flow is used.
I didn't think about it because, to me, it's like saying "cocoon is useless if the sitemap is not used".
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.Design-wise it's difficult to adapt the G-T-S pattern to an incoming stream of data,
OK, maybe "design-wise" is wrong. What about "semantically" instead?
Nop, not even there. There is no "directionality" in the concept of "generator" or "serializer" (think of them outside the cocoon context): the directionality is *only* in what input stream is given to the generator and what outputstream is given to the serializer.
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)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?
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.
You are right saying that webdavapps can be done pretty much already with what we have (and Guido showed us a basic implementation of it) but you already pointed out how cumbersome and verbose this is.
I agree that this should go away: the sitemap should be more friendly to all those request-with-payload, no matter what the payload is (multipart/encoded,webdav,soap,xml-rcp), but a few issues:
1) it should not be DAV-only since DAV is just another xml-over-http. DAV-specific functionality should be in the implementations not in the abstractions.
2) pipeline dynamism should be avoided at all costs (otherwise the entire caching design can be thrown down the drain)
3) DAV functionality should *not* be composable just like normal request pipelines (meaning that webfolders-like functionality should be a behavior of the composition of components, not an implementation of a particular component). This allows for easy webdavapp creation. At the same time, creating a simple webfolders-like approach should be as easy as composing a few pipeline.
4) sitemap semantics should be kept back compatible and overlap with current semantics minimized
The reason for the above is simple: if the webdavapp behavior is written in a component (as it is for mod_dav for example), people will just use it and not experiment with alternative implementations.
I, on the other side, want people to think at webdav (or all other xml-over-http protocols) as just http++, meaning that, with little effort, they can expose *parts* of their webdav-enabled URL space with different behaviors, just by modifying how the input is handled in matching a different pipeline.
-- Stefano.
