On Fri, 2002-04-26 at 11:32, Kendall Clark wrote: > >> Thus, > >> > >> GET /articles/500/edit GET /articles/500/print > > ian> To me that doesn't seem to make sense. All the actions in > ian> WebDAV are represented as methods (GET, COPY, etc). In a > ian> browser it's different -- the methods are really only GET and > ian> POST, which are overloaded with other semantics anyway. > > Sure, browsers just do get and post, today. But, a web application > itself can be a DAV client, offering a browser-UI.
That won't really effect what we're doing. > ian> I think it makes most sense to only have the resource name in > ian> the URL, i.e., /articles/500. Or maybe /article-500, since the > ian> "articles" collection is not really that meaningful, > > Of course it is, as others have noted. I have several such collections > in my main Web app: > > /images > /articles > /authors > /subjects But the next level is highly contextualized in a way that is difficult to generalize over other collections. /articles/500 is easy enough to parse, but then if you have a heterogeneous collection /mideast, what does /mideast/500 mean? Of course /articles could be a meaningful and useful collection. But it often exists not because it's a useful collection, but because it's an easy way to write a servlet (i.e., a servlet that handles the article type). Perhaps a more generalized query mechanism would be useful, like any collection would contain a /articles collection that would isolate the articles in that collection (including the root collection)... Anyway, 500 isn't a good identifier. /articles/500 is a fine identifier, but I feel like that will make the hierarchy deeper than it needs to be. That you are referring to an article does not necessarily mean you have a meaningful collection of articles which WebDAV can manipulate. > ian> If you use /articles/500, then maybe /articles?delete=500 might > ian> be the best way to delete, or maybe /?delete=article-500... but > ian> /article-500?delete might be fine... > > That's pretty much in violation of the spirit of the HTTP 1.1 RFC, as > I understand it, which says that GET is supposed to be both idempotent > *and* safe. Using GET to *delete* the resource is not a safe > operation. That's what DELETE is for, after all. (And it doesn't > matter that a browser can't do DELETE; that's what Web apps that speak > WebDAV to other parts of Webware are for.) > > In short, I find GET /collection/member-uri?query=delete to be > completely bonkers, but YMMV. :> Yes, I agree. Perhaps delete was a bad example -- you get forced into GET because of how browsers work :( I feel the same about /articles/500/printable -- I think that should be /articles/500?printable or somesuch. The resource you are fetching isn't "printable", it's a form of "/articles/500". To put an action in the URL implies that it's a unique resource, not a form of a resource that's available under a different URL. > >> Of course, with WebDAV, you want to do > >> > >> DELETE /articles/500 > >> > >> rather than > >> > >> GET /articles/500/delete > > ian> Yeah, I'd like these two to be closer together. > > Why? DELETE is clearly, to my mind, the http method to use to, uh..., > delete a resource from urispace... Overloading GET to do that might be > ncessary for existing-browsers interface, but not for WebDAV. I'm saying the GET form shouldn't look like it's pointing at a completely different URL than the DELETE form. > ian> Well, the obvious way would be to do respondToDelete, > ian> respondToCopy, etc., just like it's currently set up. It would > ian> be good to put in more graceful failures -- basically passing > ian> back the right (failure) response code (not implemented, I > ian> suppose). > > Yeah, as soon as I sent the first message talking about 'callbacks', I > knew it was wrong. No need for that. > > However, digging into the DAV RFC more, I've noticed that the > framework can do more than parse requests, build responses, and route > them to the right spots; I think it can include a good deal of the > resource property management stuff and the lock management. Definitely... at least once we have WebDAV working at all :) Property management and locking is something I think we can forget for the first version. > >> >From the point of view of HTTP, GET is idempotent and "always" > >> >just > >> returns the present state of the URI. But on the server side, > >> what constitutes the present state of the URI, and *how* it's > >> constituted, is (or can be, anyway) URI-specific, and as far as I > >> can tell that goes for WebDAV methods, too. > > ian> I know, I'm confused about this too -- I suppose you could > ian> return and accept things differently based on the user agent. > > There's actually a section in the DAV RFC that talks about > this... 5.4 Source Resources and Output Resources. Ah, yes, good reference. So while you might browse to /articles/500, you might access /manage/articles/500 to get and save the actual source of the article (sans all superfluous styling). Or maybe /articles/500?source, or /articles/500/source... (Specifically thinking of Web Folders, /manage/articles/500 would be the easiest to work with -- in fact, you'd probably want /manage/articles/titles/Middle-East%20Conflict since it's hard to provide other sorts of navigation beyond URL names, AFAIK). > What everyone seems to have agreed on so far is that mod_dav is > appropriate for dealing with Source Resources (in Webware's case, this > is roughly PSP, Servlet, Cheetah, and Python text files in the > filesystem of the origin server, plus other bits I'm forgetting, maybe > MiddleKit models and ancillary SQL...), I think mod_dav is appropriate for filesystem-based source resources, with minimal access control (via .htaccess). With WebDAV, I think *all* access will be primarily for source resources -- modifying an output resource is not useful, since you can't save it if it's dynamically generated. I don't think source/output resources is the distinction you are looking for. For instance, in a Wiki the source resource is the raw text of the page. The output resources is the text, formatted for HTML, with links for editing and other actions. Ian _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
