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 Tue, 29 Jul 2003 15:28:45 GMT
Stefano Mazzocchi wrote:

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

Nice explanation, thanks. But then what when an environmental constraint 
is simmetry? ;-)

>> I see that you don't particularily like the "web folders" metaphore, 
> 
> 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)

OK, then you have to recognize that, usability wise, might be somehow 
uncomfortable for Joe User to drag "my.xls" and find "my.xml" popping 
out. It would be extremely cool, though. :-)

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

Definitely so. 302 on webdav are a PITA: infact, even with HTTPClient, 
you have to tweak the apache conf to be able to handle redirects.

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

Because, as you point out later:

> 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

So that getting via webdav ?view=edit is out of question.

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

And you're definitely right here: I was way too much infected by the DAV 
syndrome. You have a strong point, and yes, the future developments 
should aim to provide new sitemap semantics and components to deal with 
this new kind of requests, where the border between context and payload 
(as NKB correctly draws) is blurred.

Having these advanced "xml-rpc" capabilities would men a hell of a lot 
for Cocoon NG: as one of my bosses pointed out this morning, this is 
exactly what would be missing to use Cocoon as the perfect EAI tool 
(yes, I know that you don't give a damn about EAI, but this is a 
scenario where Cocoon would just *rock*).

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

Yes. My point was that plain HTTP should be the "public" site, and DAV 
the administration part. But then again, this should be handled 
differently and kept in sync, so I concur.

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

Sweet. :-) Can't wait for blocks then.

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

No, I don't think we're there yet. Even though Linotype is a very good 
proof that flow goes way beyond the traditional form-based webapps, I 
still think that there should be room for more declarative 
("classical"?) approaches using only the beautiful sitemap semantics.


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

Definitely: consider me sold.

>  2) pipeline dynamism should be avoided at all costs (otherwise the 
> entire caching design can be thrown down the drain)

Makes sense.

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

I didn't quite follow here... care to spend a few more words?

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