RE: Allow: header and supported methods

I'd also be interested in working on this.  I've got a long history of
fighting this battle -- NOTIFY, IMPP bofs, GENA involvement, proprietary
implemenations, etc.

lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Wednesday, August 15, 2001 8:04 AM
> To: ietf-dav-versioning@w3.org
> Subject: 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 12:10:01 UTC