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

[Martin Hoffmann]

Greger V. Teigre quoted Dragos Vingarzan:
> 
> So let me be specific:
> - the process model

Usually, I am much in favour of a multi-processing model as opposed to
multi-threading. Apache 1.3 was rock-solid because of this. However, the
use of shared memory in SER makes the whole exercise quite pointless.
You get the drawbacks of multi-threading (one process can corrupt the
memory of all processes) with the drawbacks of multi-processing (harder
to program).

>    - believe it or not, I might want to write a module that needs more
> processes to be efficient. 

I can't really see this point but I don't know enough about all this
3GPP stuff to seriously comment on it. Somewhere down the road dialogs
where mentioned. Sounds to me that the stuff is overly complex. Not that
I am in any way surprised given that this is Telco designed.

> SER is no longer "just a SIP proxy".

But it is just that. I don't really like all the attempts to make it
more than that (which is the main reason why I don't use SEMS). SER is a
proxy and a registrar. Everything more fancy shall be done somewhere
else.

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

But that does exist now. It's somewhat miss-leadingly called selects.
 
> - 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.

For me, the script is the main reason as a service provider to use SER.
If a customer has a problem with a certain device, I can have a look at
a trace, see what's wrong and fix this. As someone running the service,
it is essential to be able to do these things merely be changing the
config file and not having to re-write part of the source and going
through the hoops of release deployment.

Fixing problems already often takes too long. If I were to implement all
those little changes "in code", I would loose even more time and, worse,
I would eventually loose track of all the changes as they would be
scattered all over the place. Now they are in the script with a short
comment above.

More in another sub-thread near you.

Best regards,
Martin