[Devel] Towards OpenSER libification

[Andrew Newton]

First, it is good to see such enthusiasm in this project.  I  
appreciate that individuals are willing to spend so much of their own  
time and energy on OpenSER.

Here is my opinion of some of these subjects:

I like the idea of breaking out the SIP parser into its own library.   
There are many cases where we have stood up SER/OpenSER processes  
with custom modules just to use the SIP parser.  As for static vs.  
dynamic and non-PIC vs. PIC, keeping an eye on performance should be  
an utmost priority.  But for the purposes I just described, a static  
library is sufficient.

As for the build tools, if there is a conversion to cmake then I  
would certainly appreciate a transition period from the current  
makefiles.

-andy

On Apr 20, 2007, at 11:49 AM, Sebastien Tricaud wrote:

> Hello people,
>
>
> following the IRC meeting, Bodgan asked me to write my thoughts here.
>
>
> * Current situation:
> OpenSER is modular, the code is separated in several directories for
> functions
> such as memory management, sip parsing, mi and other stuff...
>
> Its current architecture looks like (read bottom-top):
>
> [ higher level operations ]
>      [ parser ] [ mi ]
>    [ base : memory ]
>
>
> * What I would like to do:
>     - Make sure each component is usable individually: I would like  
> to use a
>         high performance SIP parser. The OpenSER one fills the  
> room. I am
>         sure this is one way to have this library having more users,
> which mean
>         used in ways OpenSER could not imagine, leading to discovering
> new bugs
>         and have OpenSER avoid SIP parsing troubles [1].
>     - Maybe replace useless(!) things like memory management, which is
> what most
>         C-written projects do. I think the base library could be  
> Apache
>         libAPR [2]. Maybe this is not the best choice, and if you  
> have a
> better
>         idea please let me know.
>
>
> * How I would like to do it:
> --> Submit patches :-) (put my money where my mouth is)
>     - #1: Get rid of current Makefiles and use a build system
> (autotools/CMake?)
>     - #2: Concatenating the actual memory management functions in a
> separate
>         library 'libopenserbase'
>     - #3: Put all SIP parser functions in a library 'libsipparser'
>     - #4: (after a release I guess) Replace memory management  
> functions
> using
>         a third party library
>
>
> * When?:
>     - I know patch #1 will be source of troubles, please let's be
> efficient.
>         Unless you have a good argument, I would like to autotoolize
> OpenSER.
>         - As Soon As Possible -
>     - Patch #2 will come shortly after Patch #1, wait two weeks for
> feedback,
>         then move to #3.
>     - For Patch #4, I think we should carefully chose a library  
> that has a
>         good license and _fits_ OpenSER requirements.
>
>
>
> [1] http://labs.musecurity.com/advisories/MU-200703-01.txt
> [2] http://apr.apache.org/
>
>
>
> Thank you very much for reading, feedback very welcome,
>
> Sebastien Tricaud.
>
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel