RE: Allow: header and supported methods

We've run into a bunch of cases where people want distributed
event notification, and will probably be adding something proprietary
in the next few years.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
> Sent: Tuesday, August 14, 2001 4: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 Wednesday, 15 August 2001 10:58:10 UTC