[AFS3-std] Re: Encoding IPvN addresses

[Simon Wilkinson]

On 10 Feb 2011, at 23:13, Andrew Deason wrote:
>> Premature optimization is the root of all evil.
>> Are you sure that the savings of a few bytes in, say,=20
>> VL_GetAddrsNewAndShiny is worth the extra complexity?
>=20
> No, but I also don't think there's much extra complexity. "Eh".

I think at this point we should be looking to solve the common case - we =
need to replace the use of afs_int32 for addresses. Anything more =
complex should really wait until we identify the need for it. Otherwise, =
we're going to end up constantly trying to design the better mousetrap.

>>> 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?
>>=20
>> It would, but then, that's not new.  I proposed a new _primitive_ =
type
>> several days ago, though someone (you?) has since described a way to
>> do what we were talking about in terms of an opaque<>.
>=20
> Yes, but IMHO, that way is very annoying.

Sadly, it's the way we're heading with many XDR structures, due to the =
lack of a flexible union type. It's actually not quite so bad in this =
case, because we're representing two types that natively are just =
comprised on a sequence of bytes. In other places in AFS, though, we've =
ended up using opaques which then go through a further layer of XDR =
demarshalling. This is obviously far from ideal.
>=20
> So I would agree with a primitive type. Do we want to keep new =
primitive
> types prefixed with "afs" like afsUUID was? Call it... afsTLV ?

I'd like to see a primitive type too. I'm not sure where you're getting =
TLV from (yet another TLA?) - would something like afsAddress not be =
cleaner?

Cheers,

Simon.