Subject: RE: Comments please!

From: Jim Whitehead <[email-masked]>
Date: Mon, 24 Jan 2000 09:53:46 -0800

> I have a WebDav / Http url problem. The problem I have, as a
> client developer, is to know when to do a propfind directory
> browsing and when to just do a get.
> An example:
> The user types that he wants to open 'http://www.foo.com/foo'. If
> /foo is a directory there is a problem. If I do a get on that url,
> the server could hand me /foo/index.htm ( or some other default
> file ), or it could generate a html file displaying the directory
> listing. But if I do a propfind, I could generate a directory
> listing from the answer.
>
> But how can I know which the users wants?

One solution is this:

If you don't know whether it is a collection, or an ordinary resource,
always perform a PROPFIND of Depth 1 on the resource.  If the resource is a
collection, you'll receive the directory listing.  If the resource is an
ordinary resource, you should just get back the properties on the resource
itself, which will be a fairly small response.  Then, if it is just an
ordinary resource, you can proceed with the GET.

Note that this would only need to be done when the program doesn't know what
kind of resource it is dealing with.  Once the program starts receiving
PROPFIND responses, it can cache that information, and check its cache
before performing the request.  While the program shouldn't depend on the
cached information being correct (it could be stale), you can certainly make
some optimizations based on the expected type of the resource (for example,
going straight to a GET request if you expect the resource is an ordinary
resource).

> Today I solve this by using a wildcard at the end of the url.
> Ex:
> 'http://www.foo.com/*' -> Do a propfind on 'http://www.foo.com/'.
> If not okay, try a Get on 'http://www.foo.com/*'.
> This gives the user a way of 'open as webfolder', without having
> to checking a checkbox. So now you can have links in xml files,
> that gives you a WebDav directory listing. Or even email it.

My concern with the "*" approach is that most non-programmer types don't
realize there are special wildcard semantics associated with "*".

- Jim

---

From: "Rickard Falk" <[email-masked]>
Date: Tue, 25 Jan 2000 08:08:38 +0100

> some optimisations based on the expected type of the resource
> (for example,

Hmm. But this doesn't solve my problem. Let's say that my website is called
'http://www.foo.com'. If I do a
get on this url, I'll get 'http://www.foo.com/index.htm' by default. But
'http://www.foo.com' is also a directory at the to level. So if a user types
'http://www.foo.com' I don't know if I should perform a Get or a Propfind,
both are valid. The user types the same thing for directory browsing in
'http://www.foo.com' and for getting the default page.

> realize there are special wildcard semantics associated with "*".

I agree.
This is why I posted this question. And probably why the 'web folders' have
to go through 'file/open' with a checkbox that say's it should be opened as
a folder.

/Rickard

---

From: Joe Orton <[email-masked]>
Date: Tue, 25 Jan 2000 11:19:58 +0000

> 'http://www.foo.com' and for getting the default page.

I think this mostly a UI problem. From the user's point of view, have two "views" 
on a collection resource; it's GET response, and the listing of collection members
from a PROPFIND response. These correspond to the traditional "web browser" mode of
operation, and the traditional "file browser/explorer" mode of operation.

Like you say, in Web Folders you have the "Open as Web folder" checkbox on open
dialog, which selects which of these views should be used for the given URI. 
Another way to do this (maybe Web Folders does this too, I've not been that side of
the fence for a while?), is to have some way of switching between modes from within
the browser; a toolbar button, or a drop-down box, or whatever.

So then, the user can browse about their web site, happily viewing their pages,
then maybe they want to move some files about, so they hit the "view collection
contents" button, and they can do that, then switch back again when they've
finished. That would be a nice interface, IMO.

joe