RE: Uncheckout, DAV.VersionSpace link, and History

Your proposal is no different, in terms of race conditions, from mine.
Between the time you receive the response and the time you send out a
request based on that response, the state of the server may have
changed.

In either case, the system deals with recovery. The content-nature
header provides for requesting exactly what you want and the server is
required to refuse the PUT if it can't match the content-nature header.
So if the situation has changed, the PUT will fail.

As for your accusation that my proposals do not seem thought out, I
personally find facts more compelling then assertions.

In regards to my "rapid fire approach", there is an author's meeting
next week and I wanted to give the author's a chance to see my proposals
before I bring them up at the meeting. However, rather than just sending
the posts to them privately, I decided to share them with the list. You
can not have it both ways Larry. Either you have openness with me
sending the proposals out to the list, or you don't. I will eventually
be making all the proposals available in a single file, once I have
finished them. Until then, anyone wanting to refer to them can check the
archives of this list.

All in all your post was offensive and unproductive. I hope you will
refrain in the future from such postings as it makes it extremely
difficult to work with you. Your attitude is consistently
confrontational rather than cooperative. If you have a problem with the
content or speed of my postings there are ways to bring the issues forth
without being insulting.

			Yaron

PS Sorry about the Microsoft mail address. Something went screw when I
sent the mail out.

> -----Original Message-----
> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent:	Wednesday, March 26, 1997 1:01 AM
> To:	Yaron Goland
> Cc:	DAV Discussion
> Subject:	Re: Uncheckout, DAV.VersionSpace link, and History
> 
> > 2.1     Problem Definition
> > 
> > It is highly probable that a single HTTP server will actually be a
> front
> > door to a number of other servers, some will support versioning,
> some
> > will not. Some servers will be able to support versioning of a
> resource
> > anywhere in their name space and some will only be able to support
> > versioning in specific parts of their name spaces. A mechanism is
> needed
> > to determine if a server supports versioning at all and if it does,
> > where.
> 
> This is a comment on this particular proposal, but I meant to 
> send it for several of the other proposals you've been floating.
> I think it's just wrong to assume that the server will know,
> from the beginning, the 'web collection' of which parts of its
> space are versioned and which are not. If versioning happens,
> it will happen on a resource by resource basis.
> 
> I think that the query capability should not be "ask the server
> which resources are versioned" but rather "ask the resource".
> This is the only reasonable object-oriented design.
> 
> That is, I reject the characterization implicit in your "problem
> statement". A single HTTP server will be a front door to a
> large number of resources, some of which are versioned and some
> of which are not, but, in general, not determininable in advance.
> 
> Just for example, there are severe reliability problems (race
> condition)
> if you ask the server "which resources are versioned", since it
> is impossible then to add versioning to a resource reliably, or
> even just to add a versioned resource somewhere else in its
> space.
> 
> If you're going to allow adding of versioning to individual resources
> reliably, then you'll need some mechanism to recover from the
> assumption
> of "no versioning" when versioning is possible, or the assumption
> of versioning when no versioning is possible. If you allow for
> recovery, then there's no general need for a mechanism of a priori
> discovery.
> 
> I'm really concerned that the robustness criteria isn't being applied
> during the generation of these proposals. It's like they've not
> really been thought through.
> 
> PROBLEM:
> 
> There's too many proposals being generated on the webdav mailing list
> (why am I getting copies of mail to 'davdisc@microsoft.com', to which
> I never subscribed, rather than w3c-dist-auth@w3.org?).
> 
> PROPOSAL:
> 
> Yaron refrain from further machine-gun delivery of proposals, and give
> us a web page of the whole smear. 30 proposals in the mail is not
> an invitation to discussion but an assault.
> 
> Regards,
> Larry
> --
> http://www.parc.xerox.com/masinter

Received on Wednesday, 26 March 1997 14:55:18 UTC