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

[Daniel-Constantin Mierla]

Hello Henning,

On 06/06/08 20:42, 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.
>   
by midnight I can have lot of new code pushed in to the tree, which can 
solve couple of my issues, so this is not the point here. Committing 
something wrong just before freeze does not mean we have to live with 
it. Doing major changes in the last minute is exposed to further delays.

I really do not see the full benefits of that route as it is now, just 
placing that code in another file, with a bit of caring some other 
aspects solves lot of other demands requested by users, fixes some 
existing limitations, by not dropping anything that code provides now.

If in the future, such route is going to be bound to TM by some specific 
hooks, then it is time to introduce it there. I think renaming it in 
send_route, or eventually having two of them: request_send_route and 
reply_send_route, with barely same code but in core, is better.

Cheers,
Daniel



> Cheers,
>
> Henning
>
>   

-- 
http://www.asipto.com