[AFS3-std] Re: AFSVol GetSizeV2 draft

[Andrew Deason]

On Fri, 4 Feb 2011 16:09:00 -0500
Derrick Brashear <shadow@gmail.com> 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
adeason@sinenomine.net