[OpenSER-Devel] SF.net SVN: openser: [4329] trunk/modules/benchmark/benchmark.c

[Bogdan-Andrei Iancu]

Hi Henning,

What do you mean by "we have to live with it" ? it sounds like something 
terrible wrong happened.

To be honest  I fail to see the logic behind of this. You and Daniel are 
complaining about some new code - based on a superficial understanding 
of the code and functionality you start formulating some gratuitous  
opinion, but without bringing any real technical arguments for this 
opinion.

I consider truly fair and respectful for a collective effort to :
    - try understand what is the idea and the code before expressing any 
disapproval.
    - if you are not able to understand, please ask the developer to 
clarify the issues for you - better that making wrong assumptions.


Again, I open to any technical comments on the code, if any.

Regards,
Bogdan


Henning Westerholt wrote:
> On Friday 06 June 2008, Daniel-Constantin Mierla wrote:
>   
>> [..]
>> I have to second Henning here in regard to a proper discussion may lead
>> to better solution. Maybe I am missing something, but from what I have
>> seen in the description and the code, binding this route to TM solve
>> just few of the demands. It is called after the buffer of the message to
>> be sent is built.
>>
>> IMO such route shall be available for all messages sent by openser, so
>> we get access in it to what is going to be sent on the network. There
>> are solutions to detect that the message is locally generated (e.g.,
>> only one via header), to decide there what to do. Apart of the benefits
>> brought now, siptrace will work for all messages, we can get make
>> available the destination ip and port, therefore filtering is more
>> flexible, also logging/accounting get access to this information.
>>
>> I believe that this is a real topic for discussion, and if it is really
>> important, we can postpone one or two days the freeze for the right
>> decision. Leaving a half solution for a full release is not a right
>> approach.
>>     
>
> Hello Daniel,
>
> i agree here to you, of course. But i think that further delaying of the 
> freeze is also not a good solution. So i think we'll probably need to live 
> with this solution for 1.4.
>
> Cheers,
>
> Henning
>
>
>