On Mon, 14 Feb 2011 17:28:22 -0500 Jeffrey Hutzelman <[email protected]> wrote:
> The remainder of the discussion has been almost entirely about > representation, though the what-to-store question has come up briefly > once or twice. I think we mostly have consensus that a new type > should be about addresses, and not something more complete, but I > could be misreading -- I have a fairly strong opinion on that > particular question. Well, I see nothing limiting us to just that one type. I don't see a problem with having an address extensible union type (no port), a "port" extensible union type (really a "transport-specific data" type), and a struct that just has those two things (an "endpoint" type). Then we have both a "just an address" type, and a convenient struct for RPCs to use as an endpoint. The decision for how many layers to include in the address specification can just be done a per-RPC basis; if something wants more than just the address and the port, just make a new struct. Actually, I see a slight problem in how I find it likely that all addresses ever encoded with this will be very inefficient. But I can live with it. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
