Hi All, I'd like to see us push another step forward on this.
My understanding is that to date, only two substantive issues have been raised with the document as published. The first is whether the proposed 'afs-union' (and also the hypothetical afs-union64) are in the correct namespace. Tom's document refers to Rx as afs3-rx, which appears justified, but was not commented on directly. There appeared to be agreement after discussion that the proposed type either should remain afs-union, or alternatively be put in an rx token namespace (rx-union? 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 for further input on the need for very large unions, on which there was no follow 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" <[email protected]> wrote: > On Mon, Mar 7, 2011 at 6:47 PM, Simon Wilkinson <[email protected]> > 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. > Feedback 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 > > > > Hi Simon, > > 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? > > > > struct { > > int type; > > opaque arm; > > } > > > > ... which I suspect might come in useful somewhere down the line. > > > > Indeed it would. I'll change the language for -01. > > Cheers, > > -Tom > _______________________________________________ > AFS3-standardization mailing list > [email protected] > http://lists.openafs.org/mailman/listinfo/afs3-standardization -- 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
