Next message: Tim Ellison OTT: "Re: DAV:revision-resourcetype"
Date: Thu, 27 Jan 2000 13:45:28 -0500
Message-Id: <10001271845.AA29491@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: DAV:revision-resourcetype
From: Tim_Ellison@oti.com (Tim Ellison OTT)
>The server often cannot guess what the appropriate storage format will
>be, based only on the first revision. For example, a choice between
>compressed and text-delta depends on how big the revisions in general
>will be, and how much stays the same from revision to revision. On
>the other hand, the user often can predict what this behavior is
>likely to be, and could indicate this to the server if it was
>permitted to do so by the protocol.
I agree, but this is purely a server implementation problem. I would be
reluctant to build into the protocol since such implementation issues are
not 'universal truths', and there is no clear boundary to the optimizations
possible by further extending the protocol.
If a user creates a versioned resource, and then an attempt to checkin
a new revision is denied because the storage format guessed by the
server is not compatible with the contents of this new revision,
I doubt the user will consider this a "server implementation problem".
The fact that this is not just a theoretical problem is illustrated by
the amount of traffic in comp.software.config-mgmt about trying to fix
things up when CVS has created a text delta file for a versioned
resource that sometimes can contain binary data.
We could leave this undefined, but since many/most versioning systems
share this problem, and share the solution (i.e. specifying the
type of resource being stored in the versioned resource), it seems
a shame not to standardize on a property that would allow these versioning
systems to interoperate.
Cheers,
Geoff