[Devel] Towards OpenSER libification

[Cesc]

Hi,

Sounds all great, but that is really a lot work (it ain't bad, just
making an observation).
The libparser thing for example may mean having to adjust all modules ...
The autotoolize thing it was discussed just a few days ago without
much support ... but I am for it if you/someone needs to go for it (i
am still dreaming of an winOpenSer ;) ). My proposal would be, if you
are really serious, to let you commit the new build system and
co-exist with the Makefiles for a while ... People need a transition
period to start loving it ... if that does not happen, the new build
system gets removed ...

Regards,

Cesc

On 4/20/07, Sebastien Tricaud <sebastien.tricaud at wengo.com> 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
>