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 Tue, 29 Jul 2003 07:59:19 GMT

On Monday, Jul 28, 2003, at 15:38 Europe/Rome, Marc Portier wrote:

>> The above weakness of URL space handling is the first thing that 
>> severely hurt the WebDAV world. [note: a bug in microsoft web folders 
>> eliminates the trailing slash from URL before sending the HTTP 
>> request, go figure! means that nobody in microsoft ever thought about 
>> webdav-editing the root of a folder (which is normally its index, or 
>> default content in ISS terms)]
>> Some say (ever Marc suggests) that the forcing of DAV to work all the 
>> actions on the same URL might be a reason for poor success, but I 
>> disagree because it doesn't take resource views into consideration.
>> 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"
>> which are all 'orthogonal' ways of asking a different view of the 
>> same resource accessing it thru a parallel URL space (but with 
>> different behaviors)
>
> I like this
>
> recognise some of my immature idea of separate URI-spaces but this is 
> a clean step further... (not separate per request-method, but separate 
> by intent/purpose/role/view)
>
> the only thing I am still strugling with is if there could be an 
> automatic way for the clients to know about these other URI's?

This is a good question and, to be honest, I don't know. HTTP allows 
for "variants" of the URI to be exposed at the response time, but, 
AFAIK, no client makes use of this and, besides, there is no semantic 
typing associated to it.

anybody else?

> I mentioned the possible use of PROPFIND somwhere down the line for 
> communicating READ-ONLY state, in this light this could be extended to 
> having a property that describes the URL or 'view' to get into 
> editing? (or at least a url to a linkbase that mentiones the different 
> allowed view-modes, their role and their URL?)

Marc, we can describe whatever we want, either in the HTTP headers 
(starting with x-) or with DAV properties (we can even come up with RDF 
as DAV properties if we want) but if the client doesn't know how to 
interpret them, what difference does it make?

> on the web-page side of thinks I guess there would just be an 'edit' 
> link on the page?

Well, not necessarely. Think of a CMS for a newspaper: the backend 
should be *strongly* hidden from the frontend with no visible 
relationship from the front.

> yep, it draws better on the reality that creation-publication is not a 
> two-way street:

exactly. only wikis are two-way streets. and, yes, in that case, I do 
see an "edit this page" link on that page which might be DAV-aware as 
well. my point is that this is not a general thing.

> the task still remains: build components so people can assemble it in 
> their own way, right?

exactly.

> you only got my eagerness to learn more sharpened here
> ready for some rough scetch of how things could look like?

coming up soon.

> yep, got that
> the browser very much remains well directed (an thus limited) to 
> _browsing_

not necessarely. in linotype, I've shown how you can use normal POST 
requests to implement a transport protocol for semistructured data 
(using xml:-separated prefixes to indicate semi-structured typing). In 
modern browsers (moz and ie) it's entirely possible to construct a 
WebDAV request directly from javascript and make the browser act as a 
full-blown dav client.

I agree that this is accademic, since there are much easier way to 
achieve the same effect (again, Linotype), but my point is that it's 
limiting to see the browser as limited to browsing as much as it is 
limiting to see openoffice/office/photoshop/illustrator as a fat client 
that simply reads/writes files on file systems.

>>>> mean an email sent to an administrator, or a workflow procedure 
>>>> being started: as easy as that, no client needed, just what we 
>>>> already got, networked shares and (maybe) a web browser: who needs 
>>>> a CMS client anymore then? Probably only CMS administrator, not 
>>>> users. Or (again) think about views/facets: being able to glue the 
>>>> Cocoon power to WebDAV might mean giving different content to each 
>>>> user. Graphics might see only images, and only in hi-rez: Cocoon 
>>>> will take care of making scaled down versions, while hiding them 
>>>> from the users. Possibilities are endless.
>>>
>>>
>>> mmm, dreaming allowed...
>>> MOVE of a product.xml-file to another productline-collection results 
>>> in a sql update on the foreign-key relation ?
>> why not. we could be as wild as doing an SVG report graph of a 
>> relational table, modify it with illustrator, save it and alter the 
>> data in the table. How about that? ;-)
>
> escape from the browser!
> web dav as the underlaying protocol to bring web's uri-power to more 
> editing targetted 'client' apps...
>
>>>>> I would love to see cocoon becoming a framework that can glue 
>>>>> together everything on the web, from stateless publishing from 
>>>>> stateful webdav applications and yeah, why not, once you can do 
>>>>> webdav applications you can do SOAP applications or XML-RPC 
>>>>> applications, they are, more or less, all XMLoverHTTP stuff.
>>>>
>>>> Oh, me too, believe me! This might be the Next Big Thing (hey... 
>>>> wait, are we ready to be 10 years ahead of the crowd? ;-)).
>>>> Now for the big question: should we leave this discussion for now, 
>>>> focusing on the upcoming release and take webdavification as one of 
>>>> the major challenges for the next generation (this alone might be a 
>>>> good reason for Cocoon 3.0 IMHO), or shoud we have some more fun on 
>>>> the topic here and now?
>> I think we should get this release out of the door ASAP, then start 
>> thinking about what's next.
>
> I agree.
>
>> 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.
>>> hehe, the avalanche has already started :-)
>>> managing the change into timing/planning and releases is a different 
>>> aspect, they can (and should) run in parallel IMHO
>>>
>>> the bigger challenge of being 10 years ahead is that these fast, 
>>> wild, non-domesticated, associated thoughts here and now aren't 
>>> mature enough to pull of anything and the discussion dries up before 
>>> it started... we shouldn't add a management constraint onto that >>>
IMHO
>> yes, but we shouldn't put too many irons in the fire either.
>
> I agree,
> but you also know my favourite nuance to this metafor:
>
> the correct abstractions and generalization could allow for smaller 
> research teams not needing to carry the 'iron' in their hands while 
> waiting to get it producing enough results to get lined up with the 
> big 'fire' again...

the irons here are not the implementations but the abstractions.

> list-discussions like this allow for peeking over the wall (==the 
> boundaries of our brains), and getting a feel of other ideas...
> (webdav isn't my typical cup of tea, but I did feel an invitation to 
> step in, and doing so did give me new ideas on how other parts of 
> cocoon or even personal projects could eventually benefit. By the way: 
> thx for that)

This is what RT are made for ;-)

> the general line of thinking and vision of the future is what ties the 
> group more then the actual implementation details (i.e. your 
> community-mantra paraphrazed?)

Totally!

--
Stefano.


Mime
View raw message