RE: Submission: deltav subset

Clients should be written in such a way that they do not depend on 
specific server restrictions. Certainly a client can expose whatever 
DeltaV behavior meets its user's needs. Such clients should be written to 
work with any DeltaV server that supports the necessary options. That is, 
clients shouldn't depend on some specific server restriction to make it 
easier to perform some logic as this would limit interoperability.

It looks like most of the guarantees below all result from linerar version 
histories. Its not clear why you would want the last restriction as it 
would make it impossible to ever roll back to an older version without 
making it "look" like a newer version (checkout, copy contents and 
properties of some old version onto the working resource, checkin).

I guess I don't see what is being added here. Clients should be written to 
request what they need from a server. The server should refuse to do 
anything it can't support. Clients should expect this and be tested 
against specific servers that meet their needs. Taking this approach will 
ensure clients will interoperate with new servers or upgrades to existing 
servers that provide additional capabilities.




"Lisa Dusseault" <lisa@xythos.com>
10/22/2001 01:04 PM

 
        To:     "Clemm, Geoff" <gclemm@rational.com>, "'Jim Whitehead'" 
<ejw@cse.ucsc.edu>, "Jim Amsden" <jamsden@us.ibm.com>
        cc: 
        Subject:        RE: Submission: deltav subset

 

The "deltav-subset" isn't a package.  Although it does bear some 
resemblance
to a package because it selects and recommends some major features, it 
also
makes some other guarantees.  Why is this necessary?

Currently, there is no way for a server to advertise the following
guarantees:
 - that it will only produce linear version histories
 - that it will only allow one checkout at a time
 - that it will only allow the latest version to be checked out
 - that it will only allow the latest version to be the version reflected 
in
the VCR

All of these guarantees, particularly combined, make it much easier to 
write
a simple DeltaV client.  Particularly, they help that client know what's
going on and present that to the user.  E.g. it's much easier to find out 
if
a resource is already checked out because only the latest version need be
looked at.

We could separate these guarantees as individual strings in the OPTIONS
response, but some of them go together, so that might be hard.  We could
also rename the string "deltav-subset" in the OPTIONS response to make it
more accurate.

Lisa

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: October 18, 2001 2:29 PM
> To: 'Jim Whitehead'; Lisa Dusseault; jamsden@us.ibm.com
> Subject: RE: Submission: deltav subset
>
>
> Jim makes a good point.  Introducing another "package" at this point
> muddies the water for someone trying to write an interoperable client.
> We have 5 packages defined already ... I believe it would
> be better to rework those package definitions later, based on actual
> experience
> with interoperating implementations, rather than defining additional
> packages now.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Thursday, October 18, 2001 5:07 PM
> To: Lisa Dusseault; jamsden@us.ibm.com
> Cc: gclemm@Rational.Com
> Subject: RE: Submission: deltav subset
>
>
> A couple of notes:
>
> * The packages concept was intended to support subsets like this
> -- why are
> they insufficient?
>
> * It might be necessary to rev. the charter of the DeltaV working group 
to
> do this work.  It's a judgement call between the Chair and the A-Ds.  I
> suspect the A-Ds are thinking that DeltaV, having achieved its
> goals, should
> now shut down.
>
> - Jim
>
>
>
> > -----Original Message-----
> > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > Sent: Thursday, October 18, 2001 1:56 PM
> > To: jamsden@us.ibm.com
> > Cc: Jim Whitehead; gclemm@rational.com
> > Subject: Submission: deltav subset
> >
> >
> >
> > I've finally gotten around to formatting the subset spec properly.
> >
> > Do we want to make this a working group document?  Right now
> it's named as
> > an individual submission.
> >
> > I've received a lot of interest in this subset from various
> groups: Adobe,
> > Merant, Teamstream, interwoven, CyberTeams.
> >
> > lisa
> >
> > PS -- the DeltaV home page on www.webdav.org doesn't list Jim Amsden 
as
> > chair, or his email address.
> >

Received on Monday, 22 October 2001 13:28:28 UTC