[Devel] Towards OpenSER libification

[Mike Williams]

If we have to move away from the makefiles (which have always worked quite 
well for me), then my vote is definitely for CMake.

Mike


On Friday 20 April 2007 12:57:14 Cesc wrote:
> 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
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel