Apologies for not commenting sooner. I believe I had conversations with Tom about at least some of this awhile ago, but I don't remember the outcome of them. It's possible you already had good answers for me, then, but I just don't remember them.
>> 2. GetCapabilities RPC Is this really the intended title? 3.1 seems to be the section on GetCapabilities. >> 3.1. GetCapabilities >> >> All AFS-3 Rx services with Tag-Length-Value RPCs MUST implement a >> GetCapabilities RPC analogous to that done for the FS-CM interface. ...but RXAFS tends to have long-lived, persistent connections to fileservers, so the capability bits can be cached until initcallbackstate or whatnot. Are we going to be querying cap bits for every vol operation? We also are not guaranteed that the results of a GetCapabilities represent the volserver capabilities when we actually call more meaningful RPCs on the volserver. I.e., by the time we actually call e.g. GetOneVolumeTLV the volserver could have restarted with a new set of capabilities. Or do we just rely on the RX layer to detect that, and re-query capabilities if we think the server could have restarted? I'm not saying that it causes any real problems, but is it worth mentioning? >> 3.1.2. Capability Bit Allocations >> >> Three new capability bit allocations will need to be processed by >> the Grand Central Registrar: >> >> VICED_CAPABILITY_DAFS Announce that this file server supports the >> OpenAFS Demand Attach File Server version 1 semantics >> >> AFSVOL_CAPABILITY_DAFS Announce that this volume server supports >> the OpenAFS Demand Attach File Server version 1 semantics I'm not sure I see what these cap bits actually do. What would DAFS-ness change about wire protocol behavior? The only other reference I even see to the DAFS cap bit in this is AFSVOL_TLV_TAG_VOL_STATE_DAFS_RAW and AFSVOL_TLV_TAG_VOL_OWNING_PROCESS, which could be found by just querying those tags. If the capabilities are just to represent supported tags, does it just exist to reduce the amount of advertised data? (Since 1 cap bit can represent many tags) >> 4.2.2. Tag Introspection >> >> The Rx procedure specification for the tag support RPC will be as >> follows: >> >> proc GetVolumeTLVTags( >> IN AFSVol_TLV_tag offset, >> OUT AFSVol_TLV_tag * tags<AFSINT_TLV_TAG_MAX> >> ) = XXX; Again, this isn't very useful if the server restarts between calls (the offset could mean something entirely different). Do we depend on RX detecting that and start over if it happens? -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
