>>>>> "ian" == Ian Bicking <ianb@...> writes:
ian> HTTP manages output resources fine, it seems. What sort of
ian> situation are you thinking of where you'd use WebDAV? I really
ian> can't think of any. Especially with HTML, where you can embed
ian> the values of properties directly in the page.
As you pointed out, source/output resources isn't exactly the
distinction I want. As I said at the bottom of my last post, I want to
use WebDAV to build Web apps that manipulate *logical* resources in
the context of REST (representational state transfer) -- i.e., what's
shaping up to be *the* W3C-blessed Web app architecture. (See
<http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage> and there's
a specific page about REST and WebDAV... that's where I'm coming from,
more or less.)
ian> So far URLs have been linked to the servlets on our servers.
ian> This has been less than optimal, but it never really mattered
ian> because most users interact with the URLs simply by clicking
ian> links, and it doesn't matter if they are less than perfect.
URI design matters to some people; I think it's too often ignored, but
that's my thing. (For example, see
<http://www.w3.org/Provider/Style/URI.html>) I think there's a lot of
sense to making GET safe and idempotent, for example. But then I'm not
terribly bright, so I feel more comfortable sticking to RFCs and
specs, unless there's a compelling reason not to. :>
ian> With WebDAV I'm specifically considering Web Folders -- they
ian> are the most compelling WebDAV client implementation right now,
ian> and many future clients will probably look like them (Mac has
ian> something similar, doesn't it?) Good URLs are *very* important
ian> for Web Folders -- the only interface you present is
ian> essentially those URLs.
Okay, that's fair enough, as long as you acknowledge that WebDAV is
more useful than the Web Folders use case; I haven't the slightest
interest whatever in this use, for example. It's just not what I find
interesting about WebDAV, especially since I have Xeamcs ange-ftp and
I don't build sites that have lots of newbies adding content,
I agree with your point, however, that Web Folders does provide a
twist on what *makes* a URI good or bad. That's an important
consideration I hadn't thought of, but it's also outside my scope of
So as long as we don't impose a particular set of assumptions about
URIs onto DAV, I'll be happy. :>
ian> Sure, in HTTP it's fine to have /articles/500 and
ian> /articles/500/print -- but that is that supposed to look like
ian> in Web Folders?
I haven't used them much, but if /articles/500 are two subdirs in a
dir on a W98 desktop called "Editorial Stuff", I think it looks
fine. But, sure, I appreciate that it has some problems.
The WebDAV spec specifically says it's okay to
ian> GET and PUT to a collection, but it doesn't say that clients
ian> have to make that easy, and I don't think they will. In this
ian> case, /articles/500 is a collection if you also allow
ian> /articles/500/print, which makes it very difficult to work
I'm not really sure it makes it *difficult*, but I can see that it
makes it less than ideal *for some use cases*. And that's fine.
ian> Titles also all of the sudden have to start making sense.
ian> "500" doesn't mean anything to the user. In fact, it means
ian> very little to the server unless it is prepended by /articles/.
ian> /mideast/500 isn't useful -- supposing /mideast is a conceptual
ian> collection, not type-based, and it can contain images and
ian> articles, then /mideast/500 is ambiguous.
Isn't that what Content-Type in HTTP response header does? Seems to
work fine on my Apache --
cmpu:~$ wget -S http://monkeyfist.com/pix/title
Connecting to monkeyfist.com:80... connected!
HTTP request sent, awaiting response... 200 OK
2 Date: Fri, 26 Apr 2002 19:59:40 GMT
3 Server: Apache/1.3.24 (Unix) mod_perl/1.26 mod_webkit/0.5 PHP/4.1.2
4 Last-Modified: Fri, 26 Apr 2002 19:58:11 GMT
5 ETag: "930b2-ce6-3cc9b153"
6 Accept-Ranges: bytes
7 Content-Length: 3302
8 Connection: close
9 Content-Type: image/gif
0K -> ... [100%]
14:59:41 (5.15 KB/s) - `title' saved [3302/3302]
And stupid ol' Netscape 4.75.foo on Linux displays it perfectly fine,
since it knows about Content-Type header too.
URIs without file extensions are almost *always* preferable because
extensions are almost always unnecessary implementation detail that's
better off hidden from almost everyone. Putting MIME types in
Content-Header is *good*.
It should probably
ian> be /mideast/articles-500, or /mideast/Recent%20Events, or maybe
ian> even /mideast/Recent%20Events.html
Gah. The least said about spaces in URIs and file names, the
ian> I'm not saying we should come up with a One Right Way to do
ian> URLs, but the way I've been using -- and I believe other's as
ian> well -- is bad UI when used with WebDAV.
s/WebDAV/WebDAV under *one particular use case*/ -- sure.
I don't want to
ian> impose a specific way to doing this, but extraPathURL won't,
ian> IMHO, work well enough.
I fully support 'fixing' any Webware assumptions of tying URI space to
filesystem. It's one of the things that's prevented me from using
Webware more than I have so far. So, yes, please!