On Fri, 4 Feb 2011 16:09:00 -0500 Derrick Brashear <[email protected]> wrote:
> > Proposed text. Yes/no? > > the current text can be interpreted contradictory so i'd say no I mean, I propose the following text as a replacement: > >>> The intention of the GetSizeV2 RPC is to provide an extension to the > >>> GetSize RPC, similar to how DumpV2 provided an analogous extension to > >>> Dump. As such, the only defined GetSizeV2 flag corresponds to the > >>> single existing DumpV2 flag, although there is no requirement that > >>> every GetSizeV2 flag have a DumpV2 equivalent, or vice versa. Unless you do in fact mean that you still find this contradictory... ? Care to clarify? > > That seems too strong to me; I saw this as > > something that is completely up to the implementation, but I was just > > suggesting how OpenAFS does it / will do it. IMHO, I don't really see > > problems with access control here, but it seems like a good default. > > perhaps my phrasing was (also) poor. intent: the same controls applied > elsewhere SHOULD be applied here. Hmm... well, I agree for making GetSize/GetSizeV2 the same, but not for making GetSizeV2 the same as DumpV2. I mean, Dumps should clearly be restricted to administrators, but I think GetSize/GetSizeV2 is less obvious. So, you don't need to apply the same controls to GetSizeV2 as to Dump, but I would offer it as a suggestion. I don't know if that's a MAY, or just something informally worded. > so a short "64 bit time" document would seem to be called for. the > ubik proposal will > also want it. do we want ns granular time? The last thing I remember suggested was "increments of 100ns", which I believe is some de-facto standard in Microsoft APIs? Personally, that sounded fine to me. We could throw a few non-controversial data types in there, if we wanted. 64-bit 100ns time, UUIDs... maybe extant error codes and some sockaddr_storage-equivalent if you really want the kitchen sink. Or just 64-bit time. > > We're going to have to change quite a few AFSVol RPCs when we update > > the time spec anyway; it might be preferable to do them all at once > > so the spec is the same for all, maybe give the new names all some > > consistent prefix/suffix, etc... > > on one hand, yes, on the other, bloating the code supporting X and X2 > and Y and Y2... Yeah, I know I know. My argument for this being a bit of a special case is that Dump has the clear equivalent of GetSize, and DumpV2 should have the clear equivalent of GetSizeV2. One could argue we're just bringing the GetSize* family of RPCs up to speed with Dump* RPCs. But I do agree that having such a potentially short-lived RPC is unnecessary overhead. Hmm, I don't know. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
