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

[Greger V. Teigre]

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?

- 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.
    - 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.
    - 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.
    - 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.

- the script
    - great thing, but I think that it was designed pre-transactions,
pre-dialogs, etc, right?
    - 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.