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

[Jan Janak]

Martin Hoffmann wrote:
> 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.

   OK, all this makes sense to me.

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

  Not really because we don't have such implementation. The current tm
  code has been tested for performance though, but the comparison was
  always done agains one of previous versions.


    Jan.