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

[Jeffrey Altman]

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.

Certainly when the number of arguments or types of arguments change,
there is a need for a new RPC.  No argument there.

>> (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?

The byte range locks discussions have brought to the surface an
interesting problem.  Some new functionality may result in changes in
behavior that will alter the end user experience or the load that is
placed on the servers.  Cell administrators do not have control over
what clients installed by their users or how their users configure those
clients.   In addition, afs clients are used to access multiple cells.
Administrators may want to support the new functionality but would
prefer that it not be used until their help desk staff is trained
and appropriate web documentation is updated.

The only way that I can think of that would allow an administrator to
upgrade their servers and affect the behavior of the clients is by
allowing the server to distribute policy flags.  These flags would not
be mandatory and clients could be configured to ignore them.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3288 bytes
Desc: S/MIME Cryptographic Signature
Url : http://michigan-openafs-lists.central.org/archives/afs3-standardization/attachments/20060224/80b83f29/smime-0001.bin