W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: Allow: header and supported methods

From: Jim Amsden <jamsden@us.ibm.com>
Date: Thu, 16 Aug 2001 13:44:43 -0400
To: ietf-dav-versioning@w3.org
Message-ID: <OF6DFFB245.E00A8400-ON85256AAA.006162D6@raleigh.ibm.com>
I agree with Geoff, but I don't think this covers Lisa's issues below.
These issues arrise not from examining supported properties, but by
actually looking at their values.



                                                                                                                        
                    "Clemm, Geoff"                                                                                      
                    <gclemm@rational.com>          To:     ietf-dav-versioning@w3.org                                   
                    Sent by:                       cc:                                                                  
                    ietf-dav-versioning-requ       Subject:     RE: Allow: header and supported methods                 
                    est@w3.org                                                                                          
                                                                                                                        
                                                                                                                        
                    08/14/2001 11:50 PM                                                                                 
                                                                                                                        
                                                                                                                        



I would like to resolve this issue for DeltaV as follows:

The DAV:supported-method values are not state based, and are explicitly
defined as such in the DeltaV protocol.

The semantics of the Allow header is unchanged from how it is defined
in 2616 (so DeltaV doesn't say anything about it, one way or the other).
Then if at some point there is consensus that Allow should be state
based, this change can be made independent of the DeltaV specification.

Cheers,
Geoff

-----Original Message-----
From: Jim Amsden [mailto:jamsden@us.ibm.com]
Sent: Tuesday, August 14, 2001 7:42 PM
To: ietf-dav-versioning@w3.org
Subject: 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 Thursday, 16 August 2001 14:06:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT