RE: Requirements Changes for Your Review

>> 3. Locking Model: Must servers support the WebDAV versioning model in
>> its
>> complete generality? (5.9.1.3)
>> 
>> [Yaron Goland]  I am not familiar with anyone who has stated that a
>> base level DAV server must support versioning. It has always been the
>> case that we would provide different levels of functionality, at
>> minimum between versioning and non-versioning systems.

Yaron's point does not make sense to me. Maybe I am confused? Versioned
stores vs. non versioned stores has a fundamental impact on naming and
identity of objects. Therefore, I would think this is a fundamental
decision. Either we are going to do versioned stores or not. Perhaps I am
missing something.

>> So language such as "advisory lock" should disappear.

While I agree with Yaron's sentiment about where implementation
specifications should appear, I do not want to see the notion of "locks
that are advisory" disappear. We think of all types of locks as advisory
only. When a lock is violated, what happens is a policy notion and can be
implemented in different ways given the state of the doucment-object and
state of transaction that is trying to break the lock. Therefore, I do want
to see advisory locks in place at a different place in the doucment perhaps.

>> types of objects to the Web: links, collections, version graphs, etc.

I am trying to find where the etc. is defined. Can you point to a document
segment that describes the new object model. I am sure we will have
something to say about it.

>> [Yaron Goland]  If we need to do something that breaks e-mail, so be
>> it. We are not about distributed authoring over e-mail. We are about
>> distributed authoring over HTTP. It is very nice to keep in
>> consideration e-mail issues but we should not randomize the group by
>> requiring ourselves to maintain interoperability. The last requirement
>> should be removed.

I agree with this sentiment. However, a requirement a store and forward
transport scheme such as email system may be used to address is consistency
maintenance in replicated versioned stores. We would like to see this
requirement be considered.

Sankar Virdhagriswaran			p. no: 508 371 0404

Received on Tuesday, 20 May 1997 21:06:33 UTC