RE: [reSIProcate] Conditional compile should not change object sizes
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).
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?
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?
<OptOutClause>
I don't want to eat a bunch of time of volunteers who have done a
GREAT job. If these rantings/critiques of an neophyte are not useful,
the bit bucket is a great place for them.
</OptOutClause>
Dennis
-----Original Message-----
From: Alan Hawrylyshen [mailto:alan@xxxxxxxxxx]
Sent: Thursday, April 14, 2005 3:26 PM
To: Dennis Dupont
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Conditional compile should not change object sizes
On Apr 13, 2005, at 13.40, Dennis Dupont wrote:
> I have been hit by this twice now:
>
> [snip]
Welcome to this most frustrating and not-nearly-exclusive-enough club!
:-)
> It appears somebody tried to address this with the ApiCheck and
> ApiCheckList
> classes. However, the only way to use them would be to pass each
> possibly
> affected class and its size to the ApiCheck class, something
> cumbersome and
> not very robust in terms of keeping up with library changes.
>
Indeed.
>
> I think a longer term solution would be to make TransportSelector an
> interface
> class (only pure virtual methods), and use a TransportSelectorFactory
> that
> could be conditionally compiled to instantiate the correct
> implementation
> class. This of course has the problem of breaking value semantics
> (sigh).
>
Ideally with the release of the next tarball, this is something that we
really MUST address. The library will have very limited utility if we
cannot create a stable ABI that doesn't change from one compilation /
config cycle to the next. At the most basic level, the size of the
DataStackLocal buffer must be fixed and the objects that are included
conditionally (Security, V6, etc) should all be padded in the cases
where they are absent so we don't have this ABI instability.
Anyone in a position to assist in making these changes? I think they
can all be backwards compatible from an API/CODE point of view, but
obviously not from an ABI point of view.
Cheers,
Alan
a l a n a t j a s o m i d o t c o m