>>>>> "terrel" == Terrel Shumway <[EMAIL PROTECTED]> writes:
terrel> WebDAV is a layer of abstraction that presents
terrel> a filesystem to its client.
Well, that's not what the WebDAV RFC says the way I read it, but there
you go. I read it, in relevant part, to say that it offers, among
other things, collection management. Every filesystem may be a
collection, in this sense, but every collection is not a filesystem,
and we should be careful to keep that distinction in mind.
/articles/ (or a WebDAV aware
terrel> delegate) is another layer of abstraction that presents a
terrel> filesystem to WebDAV.
No, actually, as I've said, in my example, /articles is a DAV
collection, and /articles/500 is a member-uri of that collection. Now,
how that eventually, if at all, maps to the filesystem of an origin
server is something that, as far as I can tell, the DAV RFC is
completely agnostic about.
>> 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?
terrel> Yes, mod_dav is more appropriate for that purpose, but that
terrel> would be for application *developers* not application
terrel> *users*. The two uses are orthogonal.
Well, it depends. The two sets also very often overlap.
I think we're all clear on the distinction, though, and I think
everyone who's weighed in on this thread agrees that mod_dav is ideal
to handle what the DAV RFC calls "Source Resources" and that we may
well want some DAV in Webware to handle "Output Resources".
terrel> That is exactly why we should not try too hard to find
terrel> something "that generalizes to all Webware URIs". Let the
terrel> servlet/container manage its own namespace.
I think, provisionally, that some parts of DAV infrastructure do
generalize: request parsing, response construction, (maybe) property
and lock management (or perhaps just parts of lock and property
management, like universally unique lock token creation, say). I'm
just suggesting that as much generic DAV infrastructure as possible
should be part of Webware out-of-the-box. I fully agree, and have been
saying in several messages, that when it comes to many DAV methods,
there are no general semantics at the Output Resources level, and
while there are general semantics at the Source Resource level,
mod_dav has that covered nicely already.
terrel> That is why /articles/ should not expose 500/delete as a
terrel> GETtable resource to a WebDAV client.
I agree. Unsafe GETs are unsound.
That kind of knowledge
terrel> need not be available outside of the servlet. It is also why
terrel> /delete is better spelled as /?action=delete:
No, it's why GET should be safe! :>
Spiders, conservative or not, do not issue DELETE methods to origin
servers, after all.
A conservative
terrel> spider would probably skip the latter. /print might be
terrel> acceptable instead of /?view=printable, because it probably
terrel> is idempotent w.r.t. GET, but it probably doesn't make sense
terrel> to WebDAV it because it is not an independent resource, but
terrel> merely a view.
Not necessarily. It may well be an independent resource, which is why
I spelled it /foo/bar/print, rather than /foo/bar?print.
Now, eventually, I think this *kind* of issue gets swallowed up by
content negotiation and media feature tags (RFC 2295). Until then,
however, the distinction between view and variant is wholly
context-specific and interest-relative.
Plus, there is a human factors angle: URLs with ? and & are ugly and
hard for most people to remember. Ordinary, non-hacker types can
remember /foo/bar/print far easier than they can /foo/bar?action=print
-- that matters, I think.
terrel> Note: Deficiencies in Webware's current handling of the URI
terrel> space surface when you start trying to divorce URIs from the
terrel> filesystem. My frustrations in trying to create a workflow
terrel> app based on this abstract resource view is what motivated
terrel> me to create URLDecoder
terrel> (http://jaguar.sourceforge.net/webware/urldecode.html) over
terrel> a year ago. Catalina's URI mapping is even better, because
terrel> it is completely controlled by servlets and containers
terrel> managing their own private namespaces, instead of
terrel> Application.serverSidePathForURL() trying to be all-wise and
terrel> all-knowing. Contexts were a step in the right direction,
terrel> but only a step.
I agree completely that the way an app server like Webware manages URI
space should make no assumptions about filesystems. That's, in my
view, the major Webware wart.
Best,
Kendall Clark
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
