[Serdev] So who/what is SER for, anyway?

[Dragos Vingarzan]

Martin Hoffmann wrote:
>
>
> > Some of you might receive this as SER bashing. But please understand
> > that I only want to point out the parts that I, for one, really hate, in
> > the hope that the future would bring something good. I think that SER is
> > a wonderful piece of software, but it just shows it's age and has some
> > cans of worms here and there.
>
> I'd like to innocently comment that the code quality could do with a bit
> of improvement. I known that I am a bit anal about coding style, and it is
> not as bad as Asterisk, but ...
>
same thing here, but I did not want to be dismissed and sent to sleep
early in this thread ;-). I do not claim that my code is clean and
clear, but some parts of SER are mind-blowing. I have a background in
programming contests and one of the most important things that I learned
there is that clear&average code is better than obfuscated&great code.
You will eventually have to come back and the first time you do and
don't understand it, you will transform it in obfuscated&bad code.
>
> I think I have headed out to understand tm about six times and every
> single attempt failed miserably. Two of them even included the drawing
> of pictures and call flow diagrams. Nope. Impossible.
>
yup, I concur... it's like there's a conspiration behind it ;-).
>
>
> > - the dialogs
> >     - again, this should be core. I think everything that is in RFC 3261
> > (at least) should be core if we want a "SIP" proxy.
>
> Does 3261 really say that a proxy needs to know about dialogs? I don't
> think so.
>
no it doesn't. Sorry, I was putting the accent on SIP and not on proxy.
>
>
> > - transport
> >     - no interface here, so defining new transports or new ways of
> > handling messages is impossible.
>
> It may be hard, but it is not impossible. I think the new TCP
> implementation in SER 2.0 allows you quite some room here.
>
I haven't seen this thoroughly, but can I then exchange messages in
memory, without having to encode/decode them? With the current
multi-cores, it is quite often that you run multiple nodes on the same
machine, so why not do this?

-Dragos