Next message: jamsden@us.ibm.com: "Re: DAV:revision-resourcetype"
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <2000Jan27.150000.1250.1459620@otismtp.ott.oti.com>
Date: Thu, 27 Jan 2000 15:06:13 -0500
Subject: Re: DAV:revision-resourcetype
<geoff>
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".
</geoff>
If "the server guessed wrong" then clearly it is a server implementation
problem.
If the server makes it a user problem (by refusing the storage request) then
I claim the server is doubly to blame!
I really think this storage issue falls into the domain of individual server
providers and not the protocol. For a start, unless you enumerate the valid
types, and the cross-product of their compatibilities, how will you state
the protocol behaviour for resources that change type?
>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.
I'm sure the problem is real; and there will be similar discussions about
dav servers that try to optimize storage by making any number of assumptions
that are later invalidated.
>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.
I claim that unless it is given the full weight of the specification it will
remain an optional hint to the server. I would have no objection provided
the client is free to not provide the hint.
Tim