Re: letting IETF build on top of Open Source technology

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Meant to reply earlier - on a trip...

On 11/3/17 5:07 AM, Phillip Hallam-Baker wrote:

On Thu, Nov 2, 2017 at 1:01 PM, Miles Fidelman
<mfidelman@xxxxxxxxxxxxxxxx> wrote:
On 11/1/17 10:35 PM, Phillip Hallam-Baker wrote:

My specifications are my code.

If you look at any of the protocol specifications for the Mesh, you
will find a reference section in the back that is generated directly
from the schema and examples taken from running code generated from
the same schema. And the running code used to generate the examples is
the same as the reference code.

That's a little bit disingenuous, isn't it - particularly since you've
written quite a bit of documentation beyond your code.
I did not say my code is my specification. Which is what a lot of
people have done in the past.

I develop the documentation and the code at the same time. Of course
there are parts of the documentation that are not code, the user
guide, requirements, etc. But every specification has normative and
non-normative sections.

More precisely, can you elaborate just a tad on HOW your "specifications are your code?"

I've taken a look at some of the documentation you've pointed at, but have yet to find any that have "a reference section in the back that is generated directly from the schema and examples taken from running code generated from the same schema" - can you perhaps give a specific reference?

And can you say just a tad more about the representation of the schema, your tool chain, and process?  (Without taking a really deep dive, what I surmise is that the Goedel tools can ingest ASN and generate code - am I reading that correctly?)



Beyond that, the point of a specification is to DRIVE implementation &
testing of multiple, interoperable implementations.  A reference
implementation is one thing, but as soon as one specific piece of code
(warts & all) becomes the "spec" - it's not really a specification anymore.
Reference code is not necessarily the same as production. Production
code should be conservative in what it sends and liberal in what it
accepts. Reference code should be the other way round. It should
complain when the sender fails to abide by the strict specification.

Now that is a very good point - well worth remembering.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]