cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Webdavapps with Cocoon
Date Wed, 30 Jul 2003 08:41:28 GMT

On Tuesday, Jul 29, 2003, at 17:28 Europe/Rome, Gianugo Rabellino wrote:

> 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 never found such a case (yet, at least).

Environmental constraint might be symmetrical themselves, but it 
doesn't necessarely imply that a solution forced by those constraints 
turns out symmetrical. By expecting so, you might rule out possible 
solutions to your problem space.

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

I agree. But this is another concern and not something that we can 
enforce at framework-design time.

> It would be extremely cool, though. :-)

if we give them pieces, people will find out very cool ways of using 
this stuff, I'm positive about it.

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

but DAV clients suck because DAV servers suck and are mostly providing 
an remote file system. change things on the server side and, hopefully, 
gears wills start moving again in the DAV world.

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

Yes, you are right.

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

Uh, didn't expect you to capitolate that soon ;-) great.

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

happy to see you agreeing.

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

eheh, yep, I knew you would have got it right away.

this is *exactly* why cocoon shouldn't focus on DAV but keep things 
open. I'm pretty sure we might found out patterns using DAV that could 
be applied to the entire SOAP/WSDL/UDDI/BPEL4WS stack, just like 
working on publishing lead patterns that could be applied to webapps as 
well.

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

Pfff, that's nothing compared to what blocks can do for you. I think 
that I'll spend some time getting you into them today (Gianugo and I 
will meet IRL to discuss these things)

>>> 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 personally think that in a few years people will find it impossible 
to consider doing anything without using both sitemap and flow (like 
today is inconcievable doing anything withotu a sitemap), but I agree 
that today is a little early for that.

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

cool.

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

great.

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

will do IRL and then report back the results of the discussion for the 
list to continue the design.

--
Stefano.


Mime
View raw message