[AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services

[Chaskiel M Grundman]

--On Friday, February 24, 2006 18:16:39 -0500 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

>
> (4) Instead of extending functionality by issuing a new RPC and then
>     supporting both the old and new forms, RPCs should be extended by
>     adding the new functions to the existing RPC and specifying a
>     Capability flag.
The usual reason to add a new RPC is because the arguments or argument 
types differ, not just the semantics. given the current rxgen-generated 
stubs, an rx client or server cannot provide different wire encodings to 
different peers based on capabilities. FetchStatus has not had to evolve 
(yet) as the changes made to it have not resulted in an on-wire change, 
only a change in semantics of previously reserved fields.

> (5) In addition to advertising new functionality, the Capabilities flags
>     can be used to provide hints to the caller of behavior the server
>     may desire.  For example, a file server may prefer that client not
>     request make SetLock requests even though the functionality is
>     supported.  These hints would not be mandatory and would simply be
>     a method by which desired policy can be distributed from server to
>     client.

Why is it a good idea to put client policy configuration in the server?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 3035 bytes
Desc: not available
Url : http://michigan-openafs-lists.central.org/archives/afs3-standardization/attachments/20060224/95de77b2/attachment.bin