[AFS3-std] Re: AFSVol GetSizeV2 draft

[Andrew Deason]

On Sat, 5 Feb 2011 19:31:42 -0600
David Boyes <dboyes@sinenomine.net> wrote:

> On 2/5/11 4:06 PM, "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:
> >
> >None.  We just don't have an rx spec yet.  We probably should; IIRC
> >Kolya wrote a document some years back that would be a good starting
> >point, if he'll let us use it.
> 
> I think that's the one that Mike Meffie cleaned up and submitted as an
> I-D a few months ago. AFAIK, he got permission from Kolya to do so, so
> we may have a start there.

Which, for reference, is here:
<http://openafs.sinenomine.net/~mmeffie/rfc/draft-zeldovich-rx-spec-00.html>

I don't think that was ever submitted, though.

> >An Rx RPC can succeed or fail.  If it succeeds, the server sends any
> >outgoing data and output parameters and then ends the call.  There is
> >no return value. 
> 
> Ugh.  Perhaps we're thinking of two different things -- the return
> code communicated in the RPC and the return code for the transaction
> code above it. I think we're crossing wires there.

But the "transaction" above it doesn't exist in a standard. While
conceptually it exists, the only place it's really documented as such is
in the existing implementation(s). So, as I read it, giving the RPCs a
successful return code is already tying us to the implementation, since
it just comes from the convention of the C librx implementation. At
least, that's how I read "if you really want to avoid making assumptions
based on the implementation..."

Personally, I'm fine with just saying "0" for now, just since it's
consistent with the other RPCs specified. Using a constant in a document
just for defining a new RPC seems like an odd place to introduce it.

-- 
Andrew Deason
adeason@sinenomine.net