On Thu, 10 Feb 2011 16:05:48 -0500 Jeffrey Hutzelman <[email protected]> wrote:
> Sure, we could build a complex type that encodes an address plus a > port plus lets you build arrays or lists or heirarchies or what have > you. But why? All of those things can be done with the existing > tools. I'd like to limit ourselves to creating a simple tool to solve > a simple problem, which is the lack of extensibility in address types. Doing something like this allows for space-optimization in what is the most common case for us; it doesn't _preclude_ other uses. It's not really any different if the encoder doesn't want to use it; the only difference is that e.g. the opaque for an IPv4 type may include multiple addresses instead of just one. The only downside here is the additional complexity, which seems very small. You can still encode several addresses that all have different address types. But it's just an optimization. I certainly don't think it's required, and the benefit may be so small that it's not even worth the time talking about. So I will readily concede given any opposition. > How about a new type of union that always sends the length of the > encoded data? This would make things easier in many other situations as well, so I'm all for it. Would that mean we're diverging from regular XDR, though? (Does it matter?) -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
