RE: Allow: header and supported methods

One problem with Lisa's summary below is when the UI shows an operation as 
unavailable when it actually is. For example, the UI might show a resource 
as locked by someone else (red in Lisa's tool), but the lock may have 
timed our, or the user may have released the lock. In this case, the UI is 
preventing the user from doing something that is actually possible. The 
correct solution to this problem is distributed event notification which 
is something we should consider adding to WebDAV at some point. You may 
even see proprietary versions of this capability in some vendor servers. 
In the meantime, your client UI should have a very prominent "Refresh" 
button, and users should make good use of it to be sure the UI is as 
up-to-date as possible.

Anyone interested in a new WebDAV working group to add event notification? 
We could call it DAVE.






"Lisa Dusseault" <lisa@xythos.com>
Sent by: ietf-dav-versioning-request@w3.org
08/14/2001 07:14 PM

 
        To:     "Ben Evans" <ben.evans@parasolsolutions.com>, <ietf-dav-versioning@w3.org>
        cc: 
        Subject:        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:42:34 UTC