On 3/19/2014 12:14 PM, Jeffrey Hutzelman wrote: >> In this case a volume query or >> a file query may be presented to the AFS cache manager by ID and the AFS >> cache manager will have to query the volume location database by ID to >> retrieve the data. The CM will use VL_GetEntryByName* to do so. > > OK, so Windows does not call VLGetEntryByID* either, then?
VL_GetEntryByID was not updated as part of the VL_*U RPC suite. Anything that previously used VL_GetEntryByID now calls VL_GetEntryByNameU with a numeric string. The fileserver internally calls the same internal function as VL_GetEntryByID in that case. > This is sort of a moot point, since there is little purpose in > restricting the by-id RPC interface when the necessarily-unrestricted > by-name interface provides a superset of its functionality. We are in complete agreement. >> Semantics changes to RPCs in general should not take place. New RPCs >> should be issued if the behavior of the RPC is going to be modified. > > That's only necessary for _backward-incompatible_ changes, and not > always even then. Particularly for RPCs that have been around ~forever, > making this determination can be challenging, but is sometimes > necessary. One of the changes proposed in this thread was for certain > RPCs to return false volume names, possibly only to unauthenticated > callers. That's certainly a semantic change, and possibly a > backward-incompatible one, but maybe not one that would actually break > interoperability in a way we care about. It's also a change that is > completely pointless to do in a new RPC while leaving the old one > alone. Returning false volume names will break deployed code so that is not an option. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
