[AFS3-std] AFS-3 XDR discriminated union primitive type I-D

[Matt W. Benjamin]

Hi All,

I'd like to see us push another step forward on this. =20

My understanding is that to date, only two substantive issues have been rai=
sed with the document as published.

The first is whether the proposed 'afs-union' (and also the hypothetical af=
s-union64) are in the correct namespace.  Tom's document refers to Rx as af=
s3-rx, which appears justified, but was not commented on directly.  There a=
ppeared to be agreement after discussion that the proposed type either shou=
ld remain afs-union, or alternatively be put in an rx token namespace (rx-u=
nion? rx-(some other qualifier)-union?).

Second, Tom, your response to Simon's comments of March 7 (included below) =
indicates there will be a revision simplifying the union type, but asking f=
or further input on the need for very large unions, on which there was no f=
ollow up.  I have the sense that silence indicates that at least no one has=
 -immediate- use for the afs-union64 type, but perhaps you yourself do?

I'd appreciate follow-up on whether I've summarized the status accurately, =
or if there are other outstanding issues.

Regards,

Matt

----- "Tom Keiser" <tkeiser@sinenomine.net> wrote:

> On Mon, Mar 7, 2011 at 6:47 PM, Simon Wilkinson <simon@sxw.org.uk>
> wrote:
> >
> > On 7 Mar 2011, at 20:46, Tom Keiser wrote:
> >
> >> Hi all,
> >>
> >> I've published a new I-D, based upon the on-list consensus from the
> other week, defining a new discriminated union primitive type.
> =C2=A0Feedback and comments are hereby invited...
> >
> > I'm puzzled as to why length isn't just the length of the arm. If
> you modify the encoding so that length is just the length of the
> encoded arm, then you can actually decode these "new" unions using an
> existing rpcgen, by encoding them as
> >
>=20
> Hi Simon,
>=20
> It was an arbitrary decision.  Actually, now that I think about it,
> this brings up an interesting question: will we ever want to use XDR
> to encode large streams of data (e.g., a next-generation dump
> format)?
>  If so, we would likely want the length field to be a hyper.  On the
> other hand, that would result in a significant increase in
> common-case
> overhead.  Should we defer that until we need it, perhaps with an
> afs-union64?
>=20
>=20
> > struct {
> > =C2=A0 int type;
> > =C2=A0 opaque arm;
> > }
> >
> > ... which I suspect might come in useful somewhere down the line.
> >
>=20
> Indeed it would.  I'll change the language for -01.
>=20
> Cheers,
>=20
> -Tom
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization

--=20

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309