[asterisk-dev] Proposal to bring pjproject back into the fold

Jeffrey Ollie jeff at ocjtech.us
Tue Jan 19 20:52:45 CST 2016


OK, I'm going to take a deep breath here...

The distributions policies against embedding libraries and statically
linking code isn't some arbitrary policy.  It's a hard-earned best practice
that's been proven over and over.

I get that it's "easier" to not work with others to solve problems and to
basically do a soft-fork of the pjproject code and embed it into Asterisk
and get it all set up "just so".

This is however, IMNHSO, short-sighted, anti-social behavior.  Asterisk
used to be pretty bad in this regard but recently has been much much
better.  I really don't want to see the clock turned back.

My recommendations:

1) Work with the pjproject upstream to convert problematic compile-time
options into runtime configurable options.  That way multiple consumers of
the library can get pjproject to work the way that they need it to without
recompiling it.

2) If #1 isn't feasible, work with the pjproject upstream to set defaults
for compile-time options that work better for Asterisk.

3) Add runtime instrumentation to pjproject so that Asterisk can determine
if pjproject is configured correctly for use with Asterisk at runtime.

4) Work with the distro maintainers to get pjproject packaged with the
compilation options that work best with Asterisk.

5) Write up good docs on how to compile pjproject from source for use with
Asterisk for those folks that like to compile with source.  Do your best to
make sure that it's easily findable in Google searches, as well as linked
to in the appropriate places from the Asterisk documentation.

-- 
Jeff Ollie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160119/c940960d/attachment.html>


More information about the asterisk-dev mailing list