cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject Re: [RT] Webdavapps with Cocoon
Date Mon, 28 Jul 2003 16:57:14 GMT
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. 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/)


Mime
View raw message