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

[Derrick J Brashear]

On Fri, 24 Feb 2006, Chaskiel M Grundman wrote:

>
>
> --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?
>
3 words: imap magic plus