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 <[EMAIL PROTECTED]> 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@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
