Re: [h323plus] Introducing PBoolean - API change alert!!!
Hi, I guess making the change won't be very hard for GnuGk and we've already started using STL wherever possible. The one thing I'm concerend about is to keep backward compatibility with older PWLib releases. Some people use really old OpenH323/PWLib versions to compile GnuGk and would prefer to keep them. Currently we look at the version numbers to see which features are available. So if we can simply define PBoolean back to BOOL for the old releases, I'm fine with the change. If you add config options to change what kind of bool PTLib uses, please give us a config symbol so we can detect what to define PBoolean to. Regards, Jan -- Jan Willamowius, jan@willamowius.de, http://www.willamowius.de/
Jan A quick check of GnuGk head shows 53 BOOL. Most of them are virtual of pwlib/openH323 code. Not too much trouble. h323plus shows 4,650 BOOL :) I am certainly supportive of moving everything over to PBoolean as long as. 1. We have a compile directive (which I think was mentioned) that subclasses PBoolean of BOOL instead of bool and that directive is available to derived applications so they can detect which PBoolean is actually being used independent of the ptlib version so legacy code can still run OK with newer versions of ptlib and as Jan mentioned we can add a typedef PBoolean BOOL for legacy compilations of GnuGk. 2. The ASN.1 compiler is changed to PBoolean (I don't know whether that has been done yet?). There certainly is a few ASN.1 files that need reparsing. 3. A clear ptlib version this will become effective of so we can all sync together to make a smooth transition. Next monday is a little short notice :) Anyway if I get sometime this week I'll check out the ptlib branch and produce a h323plus branch and just see what breaks :). Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Jan Willamowius Sent: Tuesday, November 20, 2007 1:01 AM To: Robert Jongbloed Cc: h323plus@lists.packetizer.com; Opalvoip-devel@lists.sourceforge.net Subject: Re: [h323plus] Introducing PBoolean - API change alert!!!
Hi,
I guess making the change won't be very hard for GnuGk and we've already started using STL wherever possible.
The one thing I'm concerend about is to keep backward compatibility with older PWLib releases. Some people use really old OpenH323/PWLib versions to compile GnuGk and would prefer to keep them.
Currently we look at the version numbers to see which features are available. So if we can simply define PBoolean back to BOOL for the old releases, I'm fine with the change.
If you add config options to change what kind of bool PTLib uses, please give us a config symbol so we can detect what to define PBoolean to.
Regards, Jan
-- Jan Willamowius, jan@willamowius.de, http://www.willamowius.de/ No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.0/1137 - Release Date: 2007/11/18 5:15 PM
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.0/1137 - Release Date: 2007/11/18 5:15 PM
Simon Horne wrote:
Jan
A quick check of GnuGk head shows 53 BOOL. Most of them are virtual of pwlib/openH323 code. Not too much trouble. h323plus shows 4,650 BOOL :)
I am certainly supportive of moving everything over to PBoolean as long as. 1. We have a compile directive (which I think was mentioned) that subclasses PBoolean of BOOL instead of bool and that directive is available to derived applications so they can detect which PBoolean is actually being used independent of the ptlib version so legacy code can still run OK with newer versions of ptlib and as Jan mentioned we can add a typedef PBoolean BOOL for legacy compilations of GnuGk.
Just so I understand, you want the following: - A configure option to use a backwards-compatible version of PBoolean, and to ensure the symbol BOOL is defined as before. This is already present - A runtime symbol that indicates whether the new PBoolean type is being used If this is the case, then I see no problem.
2. The ASN.1 compiler is changed to PBoolean (I don't know whether that has been done yet?). There certainly is a few ASN.1 files that need reparsing.
It's simple find and replace. I've just checked in a new version of ASNParser that uses and outputs PBoolean.
3. A clear ptlib version this will become effective of so we can all sync together to make a smooth transition. Next monday is a little short notice :)
Understood
Anyway if I get sometime this week I'll check out the ptlib branch and produce a h323plus branch and just see what breaks :).
Sounds good. 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
Craig I think we all are in agreement. Inline...
-----Original Message----- From: Craig Southeren [mailto:craigs@postincrement.com] Sent: Tuesday, November 20, 2007 7:19 PM To: Simon Horne; opalvoip-devel@lists.sourceforge.net Cc: Jan Willamowius; Robert Jongbloed; h323plus@lists.packetizer.com Subject: Re: [h323plus] Introducing PBoolean - API change alert!!!
Jan
A quick check of GnuGk head shows 53 BOOL. Most of them are virtual of pwlib/openH323 code. Not too much trouble. h323plus shows 4,650 BOOL :)
I am certainly supportive of moving everything over to PBoolean as long as. 1. We have a compile directive (which I think was mentioned)
Simon Horne wrote: that subclasses
PBoolean of BOOL instead of bool and that directive is available to derived applications so they can detect which PBoolean is actually being used independent of the ptlib version so legacy code can still run OK with newer versions of ptlib and as Jan mentioned we can add a typedef PBoolean BOOL for legacy compilations of GnuGk.
Just so I understand, you want the following:
- A configure option to use a backwards-compatible version of PBoolean, and to ensure the symbol BOOL is defined as before. This is already present
Great!
- A runtime symbol that indicates whether the new PBoolean type is being used
If this is the case, then I see no problem.
This is there so even if the existing code is not updated a simple compilation chech can advise the developer to use the backwards compatible compilation.
2. The ASN.1 compiler is changed to PBoolean (I don't know whether that has been done yet?). There certainly is a few ASN.1 files that need reparsing.
It's simple find and replace. I've just checked in a new version of ASNParser that uses and outputs PBoolean.
Great! Should we reparse or just globally replace the asnparser generated .h/.cxx files? I suppose it doesn't matter...
3. A clear ptlib version this will become effective of so we can all sync together to make a smooth transition. Next monday is a little short notice :)
Understood
Set a ptlib version number for the transition and a few weeks to get things in order and lets do it. Jan and I can work together to ensure things go smoothly. Simon No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.1/1140 - Release Date: 2007/11/19 7:05 PM
participants (3)
-
Craig Southeren -
Jan Willamowius -
Simon Horne