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

[Greger V. Teigre]

So, do we have a volunteer for tm moduel rewrite?! :-D
g-)

Jan Janak wrote:
> 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.
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/547ded45/attachment.htm