[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: going back to stone axes
Bancroft Scott writes:
> This argument is similar to the assembler vs. C arguments that I heard
> years ago - By working in C one is seduced into writing inefficient
> code, C relieves you from focusing on making algorithms efficient, C
> makes it easy for you to write convoluted code, C compilers sometimes
> generate invalid code, C requires a learning curve and we all already
> know assembler, etc.. Rubbish! ASN.1 is an excellent message
> modelling tool.
[...]
> Fact is that by allowing you to focus on the design of messages
> instead of the bits on the wire you can end up with a much better
> protocol design.
Just to focus us a bit, you are speaking in generalities. What exactly
is it that ASN.1 is going to permit us to do that simply expressing
the components of one of the certificates or other messages directly
will not?
The bits aren't especially complicated here. In fact, in general, they
are usually very simple from what I can tell. The complicated part of
getting a protocol right has always been, for me, figuring out what
you want the thing to do properly, never actually expressing the bits
and exchanges once you've figured it out.
When doing the experimental certificate format I was working on
recently, which employed a binary encoding, figuring out the encoding
took about thirty seconds. "We need a date format." "Okay, how about
a 32 bit number of seconds since 1970." "Sounds fine. We need to
express strings." "Number of bytes followed by the bytes?" "Fine."
This business of it being complicated to worry about "the bits on the
wire" has always seemed bogus to me.
I will also note that simply having to read the ASN.1 documentation
probably consumes more time than it can save in any given programmers
lifetime. For me, this is a sunk cost, but perhaps I can help others
avoid it.
Perry
Follow-Ups:
References: