[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
going back to stone axes
email@example.com (Carl Ellison) wrote:
> I don't wish to get into a religious war -- especially since I've been
> in battles in that war often enough in the past -- but I believe this
> reply is a solid example of what I find wrong with ASN.1 and part of what
> I consider to be its misuse. ASN.1 is *so* general that it seduces you
> into adding choices in order to avoid conflict during the standard
> definition process. It is extremely good at that. With ASN.1 you can
> defer almost all the battles which would otherwise reduce a standards
> effort to a shouting match.
> The other side of that seemingly positive coin is that the implementor
> is left to deal with the conflict which the standards committee postponed.
> That requirement adds both work at the desk of the implementor and
> CPU cycles executed during runtime.
> I would strongly advocate starting with a blank sheet of paper and
> avoiding ASN.1 during our process -- to avoid this very seduction.
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. If you already have it clear in your head the sorts
of things you don't want to do in ASN.1, then don't do them. Simple
as that. To avoid C because it allows you to write inefficient code
makes no more sense than avoiding ASN.1 because it allows you to go
wrong in message design. 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.