[AFS3-std] Re: Encoding IPvN addresses

[Andrew Deason]

On Thu, 10 Feb 2011 17:40:47 -0500
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> > Doing something like this allows for space-optimization in what is the
> > most common case for us
> 
> Premature optimization is the root of all evil.
> Are you sure that the savings of a few bytes in, say, 
> VL_GetAddrsNewAndShiny is worth the extra complexity?

No, but I also don't think there's much extra complexity. "Eh".

> > 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?
> 
> 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<>.

Yes, but IMHO, that way is very annoying. It makes it so the structure
description isn't directly in the xg, and you just need to specify "then
decode this as a struct foo in XDR". This is annoying both because it
means the structure data is specified elsewhere, and what the wrapped
structure is is an additional piece of information the application must
supply in order to get any useful information. It's like passing void*s
everywhere and relying on comments to say "this is actually a foo*".

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 ?

-- 
Andrew Deason
adeason@sinenomine.net