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.
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? ;-)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 ?
escape from the browser!
web dav as the underlaying protocol to bring web's uri-power to more editing targetted 'client' apps...
I think we should get this release out of the door ASAP, then start thinking about what's next.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 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 :-)yes, but we shouldn't put too many irons in the fire either.
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
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.
