From: Lauri Pesonen Date: 2007-05-07T21:23:06+09:00 Subject: Re: C DSL anyone? On 06/05/07, Brian Candler wrote: > > The difficulties come with more complicated messages. What if I have a > > struct used elsewhere in the system that should be a part of many > > different message types? > > The thought which struck me when reading this was: "ASN.1" > > OK, it's horrible, but it does pretty much exactly what you ask, and has its > own (standard) DSL for describing the message formats. So if you could find > a good C library which reads ASN.1 and outputs code to parse messages in > BER/DER format, maybe that would be an alternative solution. You do have a point. I agree that ASN.1 would be able to handle all possible message payloads. I've never used ASN.1 personally and my impressions of it are that it is, as you say, horrible. I laso feel that it is overkill in this case. I mean that I don't need a general solution to my problem that is capable of describing all possible message types. I'm trying to make it less painful for the other developers in the team to create new message types and as far as I can tell most of the message types we'll have will be very simple, flat structures. We'll occasionally come across a more complicated messages, but those can be implemented by hand if need be. In many cases we do not need the marshalling and to_text functions: to_text is used only for logging, and marshalling is only necessary if the message is crosses process boundaries. Never the less it would be nice to have these functions for all message types, because i) it nice to get human readable log messages, and ii) having mashalling functions available allows us to move components from one process to another almost transparently without having to worry about breaking the messaging. > The standards documentation is comprehensive, if not easy to read: > http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf > http://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf Thanks for all the links. I'm hoping that I can avoid using ASN.1. On the other hand we're doing SNMP as well, so I'll probably have to get my hands dirty at some point. I'll chug along with my approach and I'll report back if I can make it work. > Brian. -- ! Lauri