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

[Dragos Vingarzan]

Andrei Pelinescu-Onciul wrote:
>
>   IMHO forking processes at run time is a bad decision.
>
and in IMHO it is also a bad decision to fork processes if you might
never use them. It is just that in some scenarios are so dynamic that
you need a dynamic server.
>
> 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 :-)
>
:) Good! But some parts are just not written to be ever modifiable.
>
> The alternative would be to rebuild a message each time a change is
> made. This would kill the performance.
>
not necessarily. A wrap around API for accessing the message parts would
do the trick. In one of my previous posts I suggested that we keep the
original buffer, plus each time that a change is made, a new pointer is
allocated for the respective header. The wrapper can determine whether
this was  changed or not by checking the pointer range. This of course
means that all calls must be performed through the wrapper, but this
also alligns with the request for a standard API for accessing the
message parts and hiding the parser.
>
> 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).
>
the developer yes, but not the user...

> 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.
>
well, sure I can. Although I wouldn't try to get a SIP stack out of SER
because there are already good ones out there. But I really think that a
more comfortable API between the modules and the parser (and generally
for the modules) would be helpful.
>
> 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).
>
Well, my itch was that the routing script does not care about
transactions and you should take care of it. Yes, dialogs are too much
to ask for, but I would enjoy a 2 level script - one as the current one,
which takes care of the transactions, NAT, etc and would be standard for
almost everyone. Then a second one which let's me concentrate on the
task that I have to solve, instead of the things done in the first level
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.
>
I agree with you, but I would add that some times problems are too far
from the code to be elegantly solved without some abstraction levels.
Anyway, there is an API now, but I just think that is too undefined and
as it forces you to always do the same things over and over, why not
move some of the code behind that API?

-Dragos