[reSIProcate] Conditional compile should not change object sizes

[Alan Hawrylyshen]

On Apr 15, 2005, at 07.34, Dennis Dupont wrote:

> Alan
>
> Thanks for the sympathetic reply.  It is always good to know when one
> is part of a club, especially one born of frustration.
>
> I am not sure if your question of assistance was aimed at me, the whole
> list or some subset of the list that is the "development team".  I have
> not been an observer long enough to even discern how this particular
> project is run (although I am assuming it is like most open source
> teams, with a dedicated core team that does the actual work).
>

It was more an open invitation.  I'm working on a tarball / package for 
a new 'stable' resiprocate.
Right now I'm hung up in some of the mechanics of getting autotools to 
build a clean tarball on many platforms.
I'm not going to try to address the stable-ABI issue for the 0.5.0 
tarball, but we (the whole project) should consider fixing this sooner 
rather than later. ApiCheck.hxx and it's ilk were written to address 
these frustrations (or at least try to catch them) by myself quite some 
time ago. Sadly it was easier than fixing the problem (once we have a 
single build mechanism, this is something we can fix).

> Two other confusions I have about your reply:
>
> 1) You mentioned "the release of the next tarball" -- I am not aware of
> any release planning or roadmap.  I am vaguely aware of an attempt at
> a 0.5.0 release "sometime soon", but that is the extent of my knowledge
> on a plan.  Did you mean that release, or some future one?  Is there a
> roadmap, even one without dates?  Is there some grander vision for the
> library than the usefulness that we each find in it today?
>


A roadmap would be a fine idea.  For now we are going to deprecate / 
remove 0.4.0 and start publishing a tarball bi-monthly or so?
Perhaps quarterly. These are just ideas at this point.  I specifically 
was thinking about the 'next 0.5.0' tarball in my comments.

> 2) ABI vs. API -- I am not sure there is a definitive API for 
> resiprocate.
> Which classes are API and which are verboten/use-at-your-own-risk?  
> This
> could be made more clear by defining a nested namespace (resip::impl or
> such) that would be in the verboten category.  Another help would be to
> separate the source for API classes into different directories than the
> implementation.  Also, is the os group of files part of the API?
>

Excellent points. There are things that are 'off limits' yet not 
clearly marked. It might be worth a one-time breakage (or provide a 
---with-strict-api option to hide the non-safe items within an impl 
namespace.  We could re-export these symbols in the original namespace. 
One thing that's been tossed around (from a packaging point of view), 
is to move the os and utility items into a 'utility' library that could 
be used safely by client code (marking things like resip::Data as fair 
game, while keeping the Thread abstraction or other items off-limits -- 
as appropriate.

Some concept of ABI versioning will be needed once we fix the bigger 
problem of keeping the ABI stable for all configure options.


Thanks for the comments, they are appreciated.


Alan

a l a n a t j a s o m i d o t c o m