On Thu, 2002-04-25 at 14:16, Kendall Clark wrote: > >>>>> "ian" == Ian Bicking <[EMAIL PROTECTED]> writes: > > ian> SAX seems a bit too low-level -- for small requests the > ian> overhead of other implementation isn't a big deal. A DOM or > ian> somesuch seems more reasonable. The XML isn't entirely flat, > ian> at least when it comes to properties (most of the other actions > ian> are much more simple, except maybe locking...) > > The choice between SAX and DOM is only partly a technical one, of > course. (Though I'm not sure how the flatness of WebDAV's XML is > particularly relevant; people write SAX code to parse arbitrarily > deeply nested XML every day, after all.) > > The problem with some of the Python DOM implementations is that memory > usage can get kinda big, and if we pay that cost for each servlet > instance, that could get a bit out of hand. That's the main reason I > suggested SAX, and there are SAX implementations that have DOMish > APIs, so it's not entirely either-or. > > At this point, this is wildly premature optimization talk, so I'll > stop. :> (Er, not before mentioning that libxml2 has nice Python > bindings now, and PyRXP is fast as bloody hell and has fairly decent > memory usage; both require 3rd party C code, but such is life.)
Well, it's one of the first things that needs to be done, so figuring out how to process the XML is a good place to start. Maybe a SAX-ish interface would be best, as we'd be translating the XML into a Python datastructure that would form the request object. We don't need to manipulate the XML in any way, just read it. > ian> The URL handling stuff will probably be fairly significant. > ian> For WebDAV to be correct, IMHO, the URLs have to point to > ian> resources in a sensible hierarchy. Using get variables to > ian> identify resources is, I think, totally out. The style I've > ian> been using, /Action/ResourceName (like /Edit/0) won't be > ian> correct either -- > > I'm not sure I understand this; to be "correct", as in a conformant > implementation of the spec? No, "correct" more like "sensible". > I've seen WebDAV used with lots of different URL patterns, including > the one I favor (for workflowish/content-rich sites): > > /collection-name/resource-name/action/action-argument > > I.e., trying to pattern URLs after Python, treating resources like > classes: > > Module.Class.Method(args) > > Thus, > > GET /articles/500/edit > GET /articles/500/print To me that doesn't seem to make sense. All the actions in WebDAV are represented as methods (GET, COPY, etc). In a browser it's different -- the methods are really only GET and POST, which are overloaded with other semantics anyway. So you have to represent the action differently, basically through variables. I think it makes most sense to only have the resource name in the URL, i.e., /articles/500. Or maybe /article-500, since the "articles" collection is not really that meaningful, it only says what "500" is supposed to refer to. I'm not sure which one is best. If you use /articles/500, then maybe /articles?delete=500 might be the best way to delete, or maybe /?delete=article-500... but /article-500?delete might be fine... though the self-destruct method is kind of VB-ish -- OTOH, both actions might be possible, with different semantics: /?delete=article-500 removes article-500 from a collection (with some form of garbage collection to delete it if it's no longer part of any collection), while /article-500?delete would eliminate the article entirely. To me, the Zope style of mixing methods and subitems doesn't seem right -- it matches Python (which doesn't distinguish between methods and instance variables), but I don't think it works with URLs. The whole point of variables is to pass extra information in addition to the identifier for the resource you are requesting. > Of course, with WebDAV, you want to do > > DELETE /articles/500 > > rather than > > GET /articles/500/delete Yeah, I'd like these two to be closer together. > ian> We'd also have to straighten out any issues with using HTTP > ian> authentication, which is the only method of authentication > ian> available to WebDAV clients. > > Yes. > > ian> I would like something fully dynamic. The particular use I've > ian> been thinking about involves having collections provide > ian> documents based on their workflow status (kind of like an > ian> inbox), where moving would also imply actions (i.e., changing > ian> that status). When you also consider permissions schemes, you > ian> really could only do this in WebKit. > > That's what I roughly want it for, too; http/uri/browser-based > workflow apps to support web sites. > > The other big issue, which you touched on, is matching WebDAV's > assumptions about URI semantics and Webware's assumptions about URI > semantics. In other words, the case of URIs that are just pointers to > filesystem locations seems rather different than how WebDAV would work > with Webware URIs, which are almost always some kind of > dynamically-assembled resource, even if there may be some kind of > filesystem thing (Cheetah template or PSP file) that is involved. WebDAV seems to be clear that the backend does not have to be a filesystem -- it's alright for a resource to exist in multiple locations and all that. To me it seems natural. But I can't see why servlets would ever be manipulated through WebDAV, and maybe not even most templates. I mean... I guess it could happen, but mod_dav would work fine for that sort of thing anyway. > I wonder if we might not just use some kind of callback scheme? If > you want a servlet to handle PUT or DELETE or COPY, you have to > implement and register a method that is called as needed. Well, the obvious way would be to do respondToDelete, respondToCopy, etc., just like it's currently set up. It would be good to put in more graceful failures -- basically passing back the right (failure) response code (not implemented, I suppose). > >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. I know, I'm confused about this too -- I suppose you could return and accept things differently based on the user agent. I.e., Dreamweaver will get a raw HTML page, while a browser would get the page with dynamically-created headers and whatnot. > I think that Zope's use of WebDAV should be revealing for how Webware > might want to use it. Perhaps... but Zope has a strong object model which makes a lot of these decisions easy. Webware doesn't have an object model (which is what I want anyway). > PS--I hate to be nasty, but like nearly every other 4Suite doc I've > ever read, that WebDAV thing is rather unhelpful. No, I didn't get anything out of that page either. Oh well. Ian _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
