- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Tue, 16 Jan 2001 11:10:05 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Tim_Ellison@uk.ibm.com Come on ... it is no more complex for a client to check for the three options responses if they require all that functionality. But it is more complex to say "OK, this server supports workspaces but not merging, so I'll keep track of activities, and then do the merge myself on each member of the change set. But wait, this other server does not support activities either, so I'll create some dummy resource on the server which I'll use to fake an activity, but then I'll need some way to find that fake activity if I'm disconnected, ... So a sensible client that needs activity or merging support would never do any of that, but would just say: "I don't work with that server". So rather than this would "decrease client complexity", I probably should have said it would "increase interoperability". So we've got two extremes: - Everything is optional (i.e. a server can pick any combination of properties and methods that it wants to support). On this extreme, we make life maximally easy for servers ... just implement exactly what you want for a particular client you have in mind. But the result is either very complex interoperable clients (trying to fake up non-provided server functionality) or decreased interoperability (just fail against any server that doesn't provide everything you need). - Everything is required. On this extreme, we make life maximally easy for clients (whatever you want, every server has it). Unfortunately, you have very few (if any :-) servers, since few servers want to support everything. Clearly we don't want either extreme, so instead, we look for combinations that logically go together ... i.e. if you implement one, it would be easy/natural to implement the the others. I think our current set of options are a good compromise between these extremes, but I just wanted to see if there were any minor adjustments that would be worth making before we go to last call. Nor is it complex for a client to lay down a set of consistent labels to get a configuration, and get a useful recovery of a configuration using a deep UPDATE. I see only benefits for keeping them separate. This is a classic example of having the client try to "fake" some functionality that the server does not provide. In most cases, either it is "easy to fake" in which case it would be equally easy for the server to fake it (and it is far more interoperable if the server does the faking), or it is actually harder to fake than you might think. In this particular example, there's nothing in the protocol that lets you tell a server "not to move" a particular label, so you cannot in any interoperable way get baseline support through the use of labels. (Although it is very easy for a server to implement baseline support with labels, since it can allocate a set of private labels that a client has no access to). Cheers, Geoff
Received on Tuesday, 16 January 2001 11:10:58 UTC