[Devel] Introduction and new module [rather long ;)]

[Bastian Friedrich]

Dear OpenSER developer community,

Before starting with my questions, I'd first like to shortly introduce myself.

I've been studying computer sciences in Freiburg, Germany, for (quite) a while 
now and now am writing my diploma thesis for the chair of communication 
systems. The work itself is done here at Collax GmbH, an up-and-coming young 
Linux company with future interest in VoIP technology.

The outcome of my work is to be published as Open Source. I'm looking forward 
to see my code in the main OpenSER tree some time :)

Initial intent
==============
The initial topic of my thesis was to provide LDAP access for OpenSER, esp. 
for the alias and user database. Unfortunately, the current model is 
restricted to a relational database model; introducing a configurable LDAP 
backend would probably only be possible by rewriting the modules in concern, 
as the definition of data paths is not a matter of "configuration" in the 
common sense, but rather a matter of "programming".

Solution
========
The solution to this problem is the implementation of a perl module within 
OpenSER. This module will make it possible for OpenSER adminitrators to 
implement arbitrary request functions by the means of perl scripts. By adding 
an easily usable LDAP interface, alias database requests will (hopefully) be 
as easy as a one or two-line request.

New possibilities
=================
A perl module within OpenSER will give a huge amount of new possibilities. 
Instead of the hassles included when implementing custom modules, a simply 
usable perl interface will provide the means to arbitrarily modify the 
routing behavior within OpenSER. Quite possibly, current OpenSER 
configuration files /may/ almost completely be rebuilt within perl.

Current state and perspective
=============================
The basic infrastructure for my module is running. Perl is integrated through 
it's embedding mechanisms (see "perldoc perlembed"). The reverse direction, 
modification of OpenSER structures from within perl, is done via XSUB 
defintions. On the perl side, reading (msg->firstline.u.request.uri) and 
updating the URI (alias_db's "rewrite_ruri") is already possible; arbitrary 
header bodies can be retrieved. There's still lots of work to do, such as a 
means to call arbitrary exported functions from other modules. Error handling 
behavior is really bad, currently... ;)

I'm planning on implementing these functions:
* Get header names
* Get header list for one name
* Get full header
* Get full body
* Get full message
* Call functions from other modules (through "find_export")
* Rewrite URI
* Modify/Add a header line


Request for comments
====================
A couple of questions are arising during my design, and I'd like to hear your 
opinions about them.

* It needs a name! :)) Current suggestions include "perl4ser" and "PerSer"
  ("Perser" is german for "Persian")
* Structure from the perl view: I'm planing on creating an OpenSER package
  plus a number of access packages for the message structures, such as
  OpenSER::Message and OpenSER::URI.
* Naming conventions: Would you prefer "perl style" naming conventions, such
  as "RewriteRURI(newuri)", or would you rather want OpenSER naming
  conventions ("rewrite_ruri(newuri)")?
* Do you have suggestions for additional functions?
* My current "GetHeader" works on arbitrary headers. Header parsing
  (parse_headers()) thus is done for all header types; I'm using "~0" (all
  ones) as the "flags" parameter. Will this create too much overhead? Should I
  restrict the call to certain header types?

Any suggestions for the project are welcome. Let me know how far you're 
interested in the "perl idea"; if you just don't mind, you probably don't 
want to take any influence... ;)

And now... For the questions.
=============================
Unfortunately, I was not yet able to find any "use these functions in your 
module" type of documentation. In some cases, it is difficult to gather the 
authors' intentions by reading the code :(
* There seems to be a relation between what can be done by the "do_action"
  and "append_new_lump" functions. My understanding is that "do_action" is
  sort of "typed" (as you add types of actions with parameters), while the
  *_lump functions let you arbitrarily modify the message. Is this correct? In
  this case, I'd rather create an interface for the "do_action" function...?
* Is it correct that there are not too many negative effects when
  calling "parse_headers" multiple times? The function will know that it
  already parsed the header types concerned and (more or less) instantly
  return - correct?
* After calling parse_headers and parse_sip_msg_uri, most "global" parsing
  should be done, i.e. the header fields plus RURI are available. Other
  parsing functions (e.g. parse_content_disposition,
  parse_content_length, ...) are rarely necessary. Right or wrong? How
  expensive are parse_headers and parse_sip_msg_uri? Would you say it is
  alright to always call these functions?

I'll probably return with more questions during the next couple of months...

Thx a lot for your time and interest,
   Bastian

-- 
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10        www.collax.com

\ To be, or not to be, those are the parameters.