Re: Allow: header and supported methods

Lisa,

If I'm understanding you correctly, what you're talking about is the
same thing as what Adobe Acrobat 5 seems to do - it appears to send a
lot of extra PROPFIND and GET requests to a DAV server to convince
itself that the file it has is the same as the one on the server,
before doing a PUT.

So what we're saying is that it can't be *certain* that it still has a
lock, but the extra information is better than not having it.

The slight snag with this comes over low bandwidth links. The extra
requests (especially the GETs) can really add lag - especially if the
typical file for versioning is a 1M pdf file.

Personally, I'd like well-behaved (and especially potentially mobile)
clients to have an advanced option to not try and keep the status
updated (and to be able to tell the server that it didn't want to
receive event notification, in a hypothetical event notification
extension, and that it was happy with pot-luck on whether the ops it
thinks it can do, it can actually do).

Ben

On Tue, Aug 14, 2001 at 04:14:43PM -0700, Lisa Dusseault wrote:
> >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:16:26 UTC