[asterisk-dev] Recommendations for using a SIP stack with Asterisk

[Matthew Jordan]

On 11/13/2012 09:00 AM, Joshua Colp wrote:
> Daniel Pocock wrote:
> 
> I think resiprocate is awesome, and it certainly does help with
> packaging and distribution but we can't lose sight that we have to use
> the stack, make it easy for community members to develop using it, and
> make a new SIP channel driver.
> 
> Asterisk has really primarily been written in C. I would go so far as to
> wager that the vast majority of our community members don't know C++
> that well and don't feel comfortable with it. I have to admit though,
> there have been a few modules written in C++ but those have essentially
> fallen to the sidelines in recent times.
> 
> My fear if we chose resiprocate is that the number of individuals who
> would actively contribute to this project would dwindle to virtually
> nothing since the burden to participate has just gone up a considerable
> amount. This would carry over to people who want to extend the
> functionality in the future. You need to know both C and C++. Of course,
> we could write a C API over the C++ API but then we'd have something
> else we would have to maintain and extend in the future as resiprocate
> continued to be developed. Is that worth it? It also makes me wonder if
> this could actually be achieved in the time frame required if my fear
> comes true.
> 
> What do others think? Am I blowing this out of proportion? As someone
> who has been around for many years, talked to contributors, seen
> patches, etc, that's my personal opinion.
> 
> Tradeoffs, tradeoffs, tradeoffs.
> 

I don't see writing an API wrapper as a trivial effort.  There are
OO/C++ idioms (inheritance, templates, etc.) that a good C++ library
will enforce on its users that require careful thought when managed by a
C API wrapper.

For example, in reSIProcate both TransactionUserMessage and SipMessage
inherit from TransactionMessage (I'm ignoring the Message object at this
point).  Let's assume for a second that we have to expose both of these
objects through the C API. There's a number of design decisions to work
through - do we treat them as a separate C objects with no relationship
(thereby breaking the explicit inheritance relationship), and duplicate
the common elements?  Do we put a separate TransactionMessage struct as
the first element in the corresponding structs, giving us
"pseudo-inheritance" and the ability to map a
TransactionUserMessage/SipMessage down to a TransactionMessage?

These kinds of decisions will change how consumers of the facade
interact, and will require careful thought.  Doing this 'organically'
will only result in yet another SIP stack with a poor layer of abstraction.

(And this doesn't even get into templates and mapping void * to type
safe objects)

It is certainly not impossible, but I really don't think this is a point
to trivialize.  Beyond the difficulty involved, there is a certain
amount of object management and translation that such a façade would
have to provide that would not be required from a C SIP stack.  This
does increase the technical burden - and the time involved in making
said stack usable in Asterisk.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org