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

[Martin Hoffmann]

Jan Janak wrote:
> Martin Hoffmann wrote:
> > 
> > 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 ...
> 
>   Any particular recommendations?

Nothing big really, just things that tend to annoy you if you have to
work with the code and are not as much into it as you probably are.
Where to find the implementation of a function (often, only a grep -r
helps), why is it parser/parse_*.c but parser/msg_parser.c, stuff like
that. Sometimes, there are surprises. Like, in module functions, 0 is
TRUE, -1 is FALSE, and >0 is "exit" which is contradicting the usual
call conventions.

Oh, and if you all could agree on a tab length or only use tab for code
level indentation but not for aligning hanging blocks, I would be
grateful. cfg.y used to be a very bad example, but it is much better
now.

> > To me the main problem with tm is that it doesn't follow The
> > Standard. If you take 3261 you can write a transaction layer and a proxy
> > core by more or less turning every sentence into a statement or two. Why
> > does tm go its own way? Why does it merge the transaction layer and the
> > proxy transaction user into one big messy thing?
> 
>   Performance reasons. RFC3261 goes a long way in suggesting
>   implementation details but it does not mean you have to follow them,
>   as long as the behavior of the proxy is correct.

Have you ever tested whether the "standard" implementation imposes a
performance penalty? Off of my head I would say, no, at least not a big
one. But it remains to remain be seen.

Regards,
Martin