On Fri, 11 Feb 2011 08:37:52 +0000 Simon Wilkinson <[email protected]> wrote:
> On 11 Feb 2011, at 03:53, "Matt W. Benjamin" <[email protected]> wrote: > > > yes. at this point, an rpc-l primitive and corresponding rxgen > > support seem like something we would need to enable manageable and > > consistent elaboration of different union types, if I at all > > understand the issues. I'm happy to make xcb conformant with this, > > for example. I am not interested in seeing this wheel invented > > several times. Is XCB appropriate for this? I wouldn't have thought we'd want a client to be able to able to interpret the callback message if it doesn't understand the callback type. (Probably don't want to muddle this thread with discussion of that, though...) > Coming at this from a slightly different angle, I think we have an > immediate need for a new address primitive. We can create, and > implement, one relatively easily. I don't see doing so as reinventing > the wheel. We have a need for both; we already have outstanding drafts that are working around the limitation of not having a TLV structure. I'm not sure I get the perceived notion that it takes longer that way. We already wanted to use the exact same structure for addresses, so just put both types in the same draft. Whereas previously you described the whole thing as an address, just stop right before you get to the address-specific parts, make a new section and a new type, and keep describing it. (Unless you are actually suggesting using the opaque-based approach?) And I haven't yet heard anything even remotely contentious about a TLV structure (except maybe the name?). On the wire, it's exactly the same as a union, except you always encode the arm length, and the default arm is an implicit opaque. That's it. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
