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 Tue, 29 Jul 2003 08:47:40 GMT

On Monday, Jul 28, 2003, at 18:57 Europe/Rome, Gianugo Rabellino wrote:

> Stefano Mazzocchi wrote:
>>>> 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.

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 

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 

> 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
>> and I want to edit, I could ask for
> 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]
>> 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

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

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

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

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.

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

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 

  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.


View raw message