>>>>> "ian" == Ian Bicking <[EMAIL PROTECTED]> writes:
ian> On Thu, 2002-04-25 at 14:16, Kendall Clark wrote:
ian> Well, it's one of the first things that needs to be done, so
ian> figuring out how to process the XML is a good place to start.
ian> Maybe a SAX-ish interface would be best, as we'd be translating
ian> the XML into a Python datastructure that would form the request
ian> object. We don't need to manipulate the XML in any way, just
ian> read it.
That's right, for processing the body of DAV requests. I was going to
suggest we think about a specific Python databinding approach; i.e.,
write a SAX handler which returns specific Python objects (a class? a
struct-like dict? Tuple?) representing the request.
Now, on the response side, we'll need to have code that creates XML,
and DOM is easier, in my view, for doing that (i.e., create a DOM
object, add leaves and branches to it, call it's toXML() method in the
right spot...); though, it may well be the case we just want to write
to a StringIO buffer...
>> I'm not sure I understand this; to be "correct", as in a
>> conformant implementation of the spec?
ian> No, "correct" more like "sensible".
I think the discussion so far suggests there is no one correct usage
pattern for DAV, so I'm a bit suspicious of this.
>> 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.
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
and so on. The trick, though, is that
PROPFIND /collection/member-uri
is not isomorphic over every collection, and that goes for the other
DAV methods, too.
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. :>
>> 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.
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.
Okay, fair enough, and there's something to be said for including as
generic as possible implementation; but I still think we have to make
it possible to override all sorts of DAV behaviors to justify the
framework nature of Webware; but I think we agree about that, so I
won't belabor it.
ian> But I can't
ian> see why servlets would ever be manipulated through WebDAV, and
ian> maybe not even most templates. I mean... I guess it could
ian> happen, but mod_dav would work fine for that sort of thing
ian> anyway.
Right, as I said. :>
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.
>> >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.
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...), but for using DAV to manage
Output Resources, we need WebDAV *in* WebKit and it needs to be
flexible enough to accomodate a reasonable range of higher-level
application semantics (perhaps leaning toward standard CMS issues) and
extensible enough to serve as a framework for whatever else someone
might want to do at that level.
So, Source Resources are Webware assets, for lack of a better word,
but in my application, for example, those constitute Output Resources,
which have semantics and objects like "article", and "multi-person
conversation", and "newswire", while in someone else's application
might be "purchase order", "invoice", and "financial contract".
I'd like to use DAV for *both* levels; for the Source Resources level,
Apache's mod_dav seems ideal, especially since it's already
developed. For the higher web application level, I think we agree that
mod_dav won't do and we need some kind of DAV framework in
Webware. The trick is to make it flexible and extensible enough so
that one person can implement
MKCOL /purchase-orders/Texas/2002/May
and another person can implement
MKCOL /articles/middle-east-conflict
while Webware's DAV handles as much of the generic bits of DAV as is
possible.
Best,
Kendall Clark
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
