[Serdev] SER's core design features(process model/parser/lumps/script) - was: So who/what is SER for, anyway?

[Andrei Pelinescu-Onciul]

On Jan 25, 2007 at 09:38, Greger V. Teigre <greger at teigre.com> wrote:
> Greger's comment: Dragos have several observations related to the core 
> design of SER, namely the process model, the parser, the lumps and the 
> script. Thus, the thread name: SER's core design features(process 
> model/parser/lumps/script).
> --------------------------------------
> 
> So let me be specific:
> - the process model
>    - believe it or not, I might want to write a module that needs more
> processes to be efficient. SER is no longer "just a SIP proxy".
>    - yes, I know about the FIFO, RPC and whatever other interfaces, but
> is anyone fully satisfied with that?

You can write a module that uses as many processes as you want as long
as you start them from the beginning. What's not possible is to have a
dynamical number of processes forked at run-time (if you want to be able
to call ser functions from them). IMHO forking processes at run time is
a bad decision.

> 
> - the parser
>    - if SIP is an extensible protocol regarding the headers, why don't
> we have an equally easy to extend parser? For example, the header name
> parser could be auto-generated from a list of configurable header names.

I think Jan already answered this.


>    - and do we really need it that fast anyway? I have seen some
> changes that push code clarity instead of insane performance, just keep
> them coming.

Yes we need it to be "that" fast, because one of the main ser goals is to be
 very fast. ser's code is not intended as a textbook example or as
 recreational lecture :-)


>    - in the end could we have a clear and nice API to work with SIP
> messages, headers and URIs? Because not everybody wants to deal with SIP
> syntax all the time, yet every module re-implements the hunt for header
> values.
> 
> - the lumps
>    - performance + memory concerns, ok, but the mechanism is a little
> perverse. First you do not (and can not) enforce even the RFC compliance
> of messages. Then if I do a change, another module can't see it and you
> just hope all will be fine.

The alternative would be to rebuild a message each time a change is
made. This would kill the performance.
Moreover IMHO RFC compliance should not be enforced. The developer is
supposed to know what he is doing and be carefull with the lump
operations (or if he finds a problem that can not be resolved with the
current api, start a thread on serdev).

>    - this goes then back to the point above - lack of an API, as an API
> would hide the internal structures in the core and let you modify and
> view modifications easily and transparently.

Sure, could you come with a proposal? Creating a sip stack out of ser is
a good ideea, unfortunately no one had the time for trying this so far.
> 
> - the script
>    - great thing, but I think that it was designed pre-transactions,
> pre-dialogs, etc, right?

Yes, it was pre-transaction, but I don't see why would this matter.
As far as dialogs are concerned, dialog support in the script was never
considered (one would need a separate script or better a separate
application).

>    - lot's of opportunities there, but too many ways of breaking
> things. If this is designed for normal users, then maybe the range of
> actions should be restricted and piped through an API that would
> eliminate most of the conformance issues that might appear.
>    - Someone needs to step in and set some boundaries here. It's great
> for people without programming experience, that do not want to write a
> module to do something new, but it is often abused by the same people
> and then hacks propagate into the modules and core. Too much flexibility
> from my point of view. You want to do something complex, then write a
> module and interface it to the script, then have a small and clean
> linking script.

I believe that people should be free to do what they like and not forced
into a limited api. There are also technical reasons: there is no way
you could provide support for the wide varieties of possible
configurations with a limited enforced api or script interface.


Andrei