Re: Re (4): collection version resources

   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