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

[Daniel-Constantin Mierla]

Hi Bastian,

a perl module is brilliant idea. I would call it 'perl' to be clear that 
adds Perl extensions to OpenSER, same as we did with mysql/postgres ... 
Such a module will bring lot of flexibility and powerful functionality 
to configuration.

See my other comments inline.

On 11/14/06 12:23, Bastian Friedrich wrote:
> 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)")?
>   
openser style would integrate better in the scription, maybe prefixed by 
'perl_' to be distinctive and suggestive, if you want to export 
functions to openser configuration script. If it is about the Perl 
library I think Perl-like style is better. So I would like to have (just 
as example):
perl_exec("/sbin/script.pl");

and inside "/sbin/script.pl" to be able to use RewriteRURI(newuri). In 
this way programming applications will look native in both sides.

> * Do you have suggestions for additional functions?
>   
Functions to access some internals of SIP message structure and global 
environment would be great, like playing with flags, dst uri, branches, 
AVPs, sockets... We can help if you have questions here

> * 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?
>   
Most of processings end up parsing all headers, for example the messages 
going through nat processing. But if you can make it work with headers 
type is better -- maybe as an improvement in next versions.
> 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... ;)
>   
I would like to play with as soon as possible, even in early stages.
> And now... For the questions.
> =============================
> Unfortunately, I was not yet able to find any "use these functions in your 
> module" type of documentation.
Maybe it can built along with this case. dokuwiki is a good place to 
start a new doc project.

>  In some cases, it is difficult to gather the 
> authors' intentions by reading the code :(
>   
All will be glad to help as much as possible and time allows.

> * 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),
do_action() is used to execute the functions exported in configuration 
script, it is like a generic function where you give the type of 
function and parameters.
>  while the
>   *_lump functions let you arbitrarily modify the message. Is this correct?
yes, lump functions are used to change content of sip messages. 
Add/remove header functions are using them.
>  In
>   this case, I'd rather create an interface for the "do_action" function...?
>   
This should have higher priority, since there is no export of *_lump 
functions for directly usage in configuration script.
> * 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?
>   
Should be no negative effect, parse functions should detect and return 
immediately if the header was parsed already.

> * 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?
yes

>  How
>   expensive are parse_headers
this is not very expensive, it parse the header in (name, body) 
structure mainly. Just few of them do parsing of header content, and 
those are parsed by default most of the time.

>  and parse_sip_msg_uri? Would you say it is
>   alright to always call these functions?
>   
I do not know what you mean by 'always' -- if is needed, sure it is alright.

Looking forward to first version.

Cheers,
Daniel

> I'll probably return with more questions during the next couple of months...
>
> Thx a lot for your time and interest,
>    Bastian
>
>