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, >> VL_GetAddrsNewAndShiny is worth the extra complexity? > > 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? >> >> 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. 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. > > 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. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
