Re: [reSIProcate] Conditional compile should not change object sizes
- From: Alan Hawrylyshen <alan@xxxxxxxxxx>
- Date: Fri, 15 Apr 2005 08:45:50 -0600
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