Subject: Re: ADSPEC format

From: [email-masked]
Date: Wed, 4 Sep 96 09:01:19 PDT

Roch,

I believe the spec defines a canonical (required) order for parameters,
by lexical order of parameter numbers.  Since new parameters must be
assigned new numbers, they will necessarily appear at the end.

I agree that the current intserv object data defns are a bit awkward,
but we have learned to live with them.  The ISI code uses fixed structs
to deal with the currently defined structures [see rapi_lib.h], but if
(when?) intserv data gets more complex, we emulate our MIT friends and
write a little intserv data structure manipulation package.

I don't have a problem with parameter lengths.  My main objection to
the current structures is the variable alignment...  probably that is
what you mean by variable padding.  JTW obviously compromised between
packing efficiency and convenience ...  somewhere on the line between
XDR and ASN.1.  Aligning all parameters on a word boundary would be
more convenient, certainly, but provide less dense packing.

It's a judgment call.

Bob Braden

---

From: Roch Guerin <[email-masked]>
Date: Wed, 04 Sep 1996 12:06:17 -0400

>assigned new numbers, they will necessarily appear at the end.

OK, I was not clear whether that was REQUIRED.  Maybe it should be
stated explicitly in the doc, if that's what we want to do.

>more convenient, certainly, but provide less dense packing.

Exactly.  I guess I feel that convenience/simplicity is preferable to
trying to pack things as densely as possible as I don't really think
this is an instance where that really matters.

Roch

---

From: Karl Auerbach <[email-masked]>
Date: Wed, 4 Sep 1996 10:45:05 -0700 (PDT)

> assigned new numbers, they will necessarily appear at the end.

Ordering by parameter number could get "interesting" in the adspec
fragments since the parameter numbers for the "override" parameters are
lower than those of the required parameters in the guaranteed fragment.

> write a little intserv data structure manipulation package.

In the current mechanism, between a parameter header and the parameter
itself, there may or may not be two bytes of padding, depending on the
alignment of the parameter header, which is, in turn, dependent on whether
it follows a service header, a 32-bit parameter, or a 16-bit parameter.  I
couldn't make a C struct fit over this.  I had to have code that
dynamically computes addresses after inspecting alignment. 

			--karl--