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