[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".
Hm, sounds a bit complicated to me. You mean that you need a process 
model where you can create more processes from a module? I don't really 
see the use case and in what way the current model is hindering you. 
Could you please elaborate?
>    - yes, I know about the FIFO, RPC and whatever other interfaces, but
> is anyone fully satisfied with that?
You are mixing FIFO and RPC into the discussion of the process model. 
I'm a bit confused?! Maybe an example (or explanation of the needs of 
the openimscore project) would help. 
>
> - 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.
I couldn't agree more. Martin has also pointed out that the module 
interface needs a revamp.  I think maybe such a revamp could form the 
core of more adaptable SER. There are too many things that each module 
has to take care of, and the API(s) available to the modules are not 
well documented. The code also has some history where some modules use 
old functions that should have been deprecated, but not been updated.  I 
agree with you, a clean interface with a clearly defined API would make 
it a lot easier to develop modules for SER.
>
> - 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.
Yes, lumps is a funny thing :-( There is a lack of abstraction here. 
Modules shouldn't have to deal with lumps, it should be an 
implementation issue in the core. Again, a clean API for manipulating 
messages should be made available to the modules, and the API could use 
lumps for implementation. The performance degradation would probably not 
be too much?!

g-)