>>>>> "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.) 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? 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 Of course, with WebDAV, you want to do DELETE /articles/500 rather than GET /articles/500/delete 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. 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. In the same way that GET causes one kind of thing when handed a URI that ultimately maps to a filesystem entity, and another kind of thing when ultimately it maps to a database SELECT and Cheetah template transform, the WebDAV HTTP extensions are going to show the same variability, doing one thing when pointed at *your* /wk/Edit/500 URI and something else when pointed at my /articles/500. Then, the WebDAV implementation in WebKit mostly handles the XML parsing, request routing, and returning whatever the callback method returns. Otherwise, I don't see how we can implement PUT, DELETE, COPY in a way that generalizes to all Webware URIs. We could just treat the underlying servlet, PSP, Cheetah, et. al. resources as static files; i.e., DELETE /wk/index.psp simply deletes 'index.psp' from the filesystem; but if that's the approach, why not just use mod_dav? The other alternative is to assume some generlish workflow semantics for WebDAV methods and then users of Webware have to fit into that range of assumptions, but that strikes me as antithetical to the notion of Webware as a framework. >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 think that Zope's use of WebDAV should be revealing for how Webware might want to use it. Best, Kendall Clark PS--I hate to be nasty, but like nearly every other 4Suite doc I've ever read, that WebDAV thing is rather unhelpful. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
