>>>>> "ian" == Ian Bicking <[EMAIL PROTECTED]> 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, typically. 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 interest. 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 ian> with. 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 --14:59:39-- http://monkeyfist.com:80/pix/title => `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 10 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 better. YMMV. 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! Best, Kendall Clark _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
