Bird 27 discussion

Ibis folks -

In reading through the minutes of the last meeting, and looking at the
response I got about it, I think part of the point of BIRD 27 was missed,
and that in fact I did an inadequate job of making it in the first place.
This added keyword is more than a mere convenience for the model maker,
although it adds that convenience as well. Bear with me through a little
reasoning here.

We had laid down a ground rule that ibis files should be e-mail friendly
and in fact that has generated a lot of follow up discussion. Recall the
discussions that ensued about the 80 character line length limits when we
were pursuing the package model data. And that has arisen a couple of
times since. We have jumped through a number of hoops to make sure that
the file remained e-mail friendly. Well, most if not all mailers, and
virtually all mail relays, impose a limit on the size of an e-mail file
as well as line limits. Left to themselves, partial file deliveries are
not that unheard of through SMTP mail. I have received several mailings
that were not all there ( and I don't mean the thinking behind them;-)).
The limit is somewhere around 60k bytes, which for any one model would
not be a problem. BUT when I try to package several models which are
intimately related to each other, such as a chip set, for example, I can
push that limit quite easily. The use of an abbreviated form such as I
am proposing removes the mandate otherwise present in the spec to include
redundancy which is only for the conveience of the parser writer.
Specifying the same numbers over and over again on the pin mapping lines
is redundant and only serves to make the parser a LITTLE easier to write.
The further rules imposed are already imposed by the Lpkg, Cpkg, and Rpkg
keywords, which accomplish the same thing in their domain. So we DO have
the precedent for doing as I suggest. The further rules are not very
involved at all for a properly structured parser to handle. And any such
redundancy I can remove is the more content bearing data I can include in
the file without getting e-mail burps.

We would not have to include NA on all lines, unless we want to
specifically force data to be defaulted, but we could simply leave these
columns out as we do with Lpin, Cpin, and Rpin now. NA would say we
really do not have the data. Since that capability is already there, we
already have the rule that says a default can be used, and all I am
adding is a new place the default might come from.

There was some question about where I would position the new keyword. I
can make a case in my own mind for it to be a modifer on [component], and
I can similarly make a case for it to be a modifer on [pin]. I am not
greatly vested in either one just now ( or somewhere other, for that
matter ), and am open to discussion of that as an implementation matter
if the fundamental priciple is agreed to. I lean toward [pin], but not
with any great conviction.

So I hope to revisit this at the next meeting, possibly briefly, and
bring it to rest at that time. Sorry I could not be at the last meeting
to make this defense at the moment, but the conflict I had was
unavoidable.

All the best,

Bob Ward bward@neosoft.com
Received on Fri Apr 14 12:19:38 1995