[AFS3-std] Re: AFSVol GetSizeV2 draft

[Derrick Brashear]

On Fri, Feb 4, 2011 at 4:29 PM, Andrew Deason <adeason@sinenomine.net> wrote:
> 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... ?

er. your use of > implied quoting :)

i didn't reread. it's fine.

>> 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.

the getsize(s) should be the same. the computational intensity of
getsize should decide who should run it
and while it may be site policy implementors will know how likely it
is to be an issue.

>> 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.

i'm fine with that too.

> 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.

100ns time, sockaddr_storage like and uuids in such a draft would be fine.

>> > 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.

this is the same problem i'm having with the (draft) ubik proposal. i
don't want something
which is an RPC which is new for one release, and then obsolete, as an
implementor. ew.

Derrick