Question about new ASN compiler
To all, Some time ago, an independent group of developers created a new ASN compiler based on the original code provided released by OPAL/OpenH323. This code created by this compiler has been used in several commercial projects that I have been involved in, and it definitely works. The big advantage is that the code created by this compiler is MUCH smaller at run-time that the original OPAL/H.323 code. As in ten times smaller. The big disadvantage is that the code created by this compiler is very different from the code created by the old compiler. The code uses C++ templates heavily, and there is no way to make it look similar. Robert and I have not considered introducing this new compiler to date because of the problems it would cause. But, we would like to hear the opinions of other people about this code. If the general consensus is that people would like to see it used, then we will put in the work to make it happen. If the general consensus is that people do think it is worth the hassle, then we will stop worrying about it :) I've copied this message to both the h323plus and GnuGk lists as this decision has obvious ramifications for both projects Craig ----------------------------------------------------------------------- Craig Southeren Post Increment – VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 Jabber: craigs@jabber.org "Science is the poetry of reality." Richard Dawkins
The big advantage is that the code created by this compiler is MUCH smaller at run-time that the original OPAL/H.323 code. As in ten times smaller.
-snip-
But, we would like to hear the opinions of other people about this code. If the general consensus is that people would like to see it used, then we will put in the work to make it happen. If the general consensus is that people do think it is worth the hassle, then we will stop worrying about it :)
Hi Craig For what it's worth, I think that that would be a very worthwhile move as a lot of potential users (like myself) of OPAL are embedded developers where every kilobyte counts. If you can save a meg or so then I the work is definitely worth some temporary instability in the code! Just my 2 cents -- Peter Nixon http://peternixon.net/
Craig I certainly I very much welcome to the idea. How it effects opal/h323plus I think will be difficult but managable as most users access the ASN.1 code via a project intermediate layer anyway making changes relatively transparent to the user. How it effects GnuGk is going to be a completely different animal and I think will require much greater scrutiny. Honestly, At this particular junction I think we should just take a break, a deep breath and put this on the back burner for a few weeks (at least) until things settle down and we can again resemble codiality and revisit the topic then. I hope we all agree :-) Simon -----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Craig Southeren Sent: Sunday, 4 November 2007 5:24 PM To: h323plus@lists.packetizer.com; opalvoip-devel@lists.sourceforge.net; GNU Gatekeeper Developer Subject: [h323plus] Question about new ASN compiler To all, Some time ago, an independent group of developers created a new ASN compiler based on the original code provided released by OPAL/OpenH323. This code created by this compiler has been used in several commercial projects that I have been involved in, and it definitely works. The big advantage is that the code created by this compiler is MUCH smaller at run-time that the original OPAL/H.323 code. As in ten times smaller. The big disadvantage is that the code created by this compiler is very different from the code created by the old compiler. The code uses C++ templates heavily, and there is no way to make it look similar. Robert and I have not considered introducing this new compiler to date because of the problems it would cause. But, we would like to hear the opinions of other people about this code. If the general consensus is that people would like to see it used, then we will put in the work to make it happen. If the general consensus is that people do think it is worth the hassle, then we will stop worrying about it :) I've copied this message to both the h323plus and GnuGk lists as this decision has obvious ramifications for both projects Craig ----------------------------------------------------------------------- Craig Southeren Post Increment – VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 Jabber: craigs@jabber.org "Science is the poetry of reality." Richard Dawkins
Hi. a smaller memory foot print would of course be nice, but the current size isn't much of a problem for GnuGk. I'd have to take see some examples of the new interface to get a clearer picture, but I would guess GnuGk would be hit pretty hard by those changes since GnuGk doesn't use much of the framework hiding the ASN classes. Thus I'd prefer to keep the old parser. Regards, Jan Craig Southeren wrote:
To all,
Some time ago, an independent group of developers created a new ASN compiler based on the original code provided released by OPAL/OpenH323. This code created by this compiler has been used in several commercial projects that I have been involved in, and it definitely works.
The big advantage is that the code created by this compiler is MUCH smaller at run-time that the original OPAL/H.323 code. As in ten times smaller.
The big disadvantage is that the code created by this compiler is very different from the code created by the old compiler. The code uses C++ templates heavily, and there is no way to make it look similar.
Robert and I have not considered introducing this new compiler to date because of the problems it would cause.
But, we would like to hear the opinions of other people about this code. If the general consensus is that people would like to see it used, then we will put in the work to make it happen. If the general consensus is that people do think it is worth the hassle, then we will stop worrying about it :)
I've copied this message to both the h323plus and GnuGk lists as this decision has obvious ramifications for both projects
Craig
-- Jan Willamowius, jan@willamowius.de, http://www.gnugk.org/
-----Original Message----- From: opalvoip-devel-bounces@lists.sourceforge.net [mailto:opalvoip- devel-bounces@lists.sourceforge.net] On Behalf Of Jan Willamowius .... a smaller memory foot print would of course be nice, but the current size isn't much of a problem for GnuGk. I'd have to take see some examples of the new interface to get a clearer picture, but I would guess GnuGk would be hit pretty hard by those changes since GnuGk doesn't use much of the framework hiding the ASN classes. Thus I'd prefer to keep the old parser.
The changes are fairly mechanical, though just too difficult to completely automate as an awk script. Essentially you have code like: obj.m_field = value; is changed to obj.set_field(value); and obj.SetTag(H245_Blah::e_BlahChoice); H245_BlahsChoice & blah = obj; becomes H245_BlahsChoice & blah = obj.select_BlahChoice(); At run time, the only semantic different is that optional fields that are absent from the encoding have no default value. So for something like: Blah :: SEQUENCE { field1 INTEGER field2 INTEGER OPTIONAL } We might have had in the past: if (obj.m_field2 != 0) and assumed a default value of the field2 was not encoded. Now if this code is changed to: if (obj.get_field2() != 0) it will assert, it has to be: if (obj.field2_isSelected() && obj.get_field2() != 0) P.S. I have actually done this conversion once before, it's a relatively big job, but 99.9% of the errors were picked up by the compiler. Robert Jongbloed OPAL/OpenH323 Architect and Co-founder.
I agree - GnuGk is not an endpoint, so its requirements for an embedded hardware can be a bit higher than it's in the case of an oridinal VoIP CPE. ----- Original Message ----- From: "Jan Willamowius" <jan@willamowius.de> Sent: Monday, November 05, 2007 10:45 PM Subject: Re: [Openh323gk-developer] Question about new ASN compiler
Hi.
a smaller memory foot print would of course be nice, but the current size isn't much of a problem for GnuGk. I'd have to take see some examples of the new interface to get a clearer picture, but I would guess GnuGk would be hit pretty hard by those changes since GnuGk doesn't use much of the framework hiding the ASN classes. Thus I'd prefer to keep the old parser.
Regards, Jan
Craig Southeren wrote:
To all,
Some time ago, an independent group of developers created a new ASN compiler based on the original code provided released by OPAL/OpenH323. This code created by this compiler has been used in several commercial projects that I have been involved in, and it definitely works.
The big advantage is that the code created by this compiler is MUCH smaller at run-time that the original OPAL/H.323 code. As in ten times smaller.
The big disadvantage is that the code created by this compiler is very different from the code created by the old compiler. The code uses C++ templates heavily, and there is no way to make it look similar.
Robert and I have not considered introducing this new compiler to date because of the problems it would cause.
But, we would like to hear the opinions of other people about this code. If the general consensus is that people would like to see it used, then we will put in the work to make it happen. If the general consensus is that people do think it is worth the hassle, then we will stop worrying about it :)
I've copied this message to both the h323plus and GnuGk lists as this decision has obvious ramifications for both projects
Craig
-- Jan Willamowius, jan@willamowius.de, http://www.gnugk.org/
participants (6)
-
Craig Southeren -
Jan Willamowius -
Peter Nixon -
Robert Jongbloed -
Simon Horne -
Zygmuntowicz Michal