RE: Allow: header and supported methods

From a server point of view, you're correct -- it's impossible to be right
all the time.  So it's tempting to say "forget it", if it's not correct why
bother.

However, from a client point of view, this information is helpful even if
it's only right 85% of the time or more.  It makes for a vastly more usable
GUI if this kind of information is available. The reason is that GUI clients
typically have buttons and menu choices for things like "checkout", "check
in", "view version history".  Both buttons and menu items can and should be
greyed out if the action they do is unavailable currently.  Alternatively,
the state of the resource can be displayed in a directory listing, where
such information helps the client decide what to do with the resource.

For state changes in particular, I'll point you to a GUI I've been working
on for a couple years:  the www.sharemation.com user interface.  It displays
a lock image that is red if the lock is taken by somebody else, green if the
lock is taken by you, and grey if it's not locked.  Although this
information may be out of date the instant the client sees it, it is
_probably_ still good.  And it's made locking much easier to use: I won't
even try to edit a file that I can immediately see is locked by somebody
else.

You can see a subtler instance of this effect in Windows Explorer, even with
Web Folders viewing DAV repositories: in the detailed view of files, you see
the size and the last-modified information about a file.  Wouldn't you think
it's useless to display this since at any time it might change?  Obviously
not.

For a third example from a versioning product: take WinCVS.  It shows
buttons in the toolbar for you to add a new file to version control.  But
this button is greyed out unless the focus of the user (the selected file)
is on a new file.  Should WinCVS not even attempt to grey out the button?
After all, WinCVS could show the button as active, thus leading the user to
believe they can add the file, but when they try it they find there is a
conflicting file already added by another user and they're forbidden to take
that action.  I find the way it works to be sufficient since the likelihood
of a problem is low. Here is a case where the greyed-out button is usually
correct, and that's enough for most users most of the time.

Now, you could argue that this whole attempt at providing information on
what a user can do is misguided and we should all be using command-line
interfaces anyway.  ;)  But those who want to provide this information have
a valid need.

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Ben Evans
> Sent: Tuesday, August 14, 2001 4:46 AM
> To: ietf-dav-versioning@w3.org
> Subject: Re: Allow: header and supported methods
>
>
>
> Please excuse a newbie question:
>
> Surely for a server looking after versioned resources, asking it
> "What If?" questions based on its current state is a bit useless?
>
> I mean, if I have a checked-out resource, and I don't have an
> exclusive write-lock on the resource, then requests to the server
> such as "If I try and commit, will I be able to?" can only
> be usefully answered by the server with: "I don't know, unless
> you try."
>
> Is there a more subtle issue I'm missing?
>
> Ben
>
> On Tue, Aug 14, 2001 at 09:53:36AM +0100, Tim Ellison wrote:
> > During the working group meeting we agreed to note this issue
> on the list:
> >
> > What does the (HTTP/1.1 defined) Allow: header mean? and should
> it be the
> > same as the (DeltaV defined) DAV:supported-method-set property?
> >
> > The meeting attendees agreed that "allowed" and "supported"
> should mean the
> > same thing, and concensus was that both should report methods that will
> > succeed for some state of the resource, not necessarily the
> current state.
> >
> > For example, a version-controlled resource can be checked-out
> or checked-in
> > and therefore only one of CHECKOUT or CHECKIN will succeed for a given
> > state of a version-controlled resource.  It is proposed that, for
> > version-controlled resources, "Allow:" and "DAV:supported-method-set"
> > include both CHECKIN and CHECKOUT (amongst others).
> >
> > Send any objections to the list.
> >
> > Regards,
> > Tim
> >

Received on Tuesday, 14 August 2001 19:15:19 UTC