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

Daniel-Constantin Mierla miconda at gmail.com
Fri Jun 6 16:05:16 CEST 2008


Hi all,

On 06/06/08 15:43, Bogdan-Andrei Iancu wrote:
> Hi Henning,
>
> Of course I'm as much concerned about bugs and stability as you are - 
> probably this is the main reason why there are so many commits just 
> before the freeze (from all developers) - the new code was kept by the 
> developers just to do as much testing as possible before committing on SVN.
>
> Even if we (like an individual) do not understand (like not my area) the 
> code from somebody else, we should give some credits on the quality of 
> the code and not start with the assumption that it breaks something :). 
> I think the project is quite large know and it  may exceed the power of 
> comprehension of the single person :)
>
> I agree that complex changes needs to be discussed in advanced, but it 
> is not applicable here - more or less this commit was the result of a 
> need from the users, need that was express on the list several time, by 
> several people, in several contexts  (see my email about the description 
> of the new route time).
>
> I will take care of enabling this route only for functions that:
>      1) make sense to  be used here
>      2) are safe to be called from here.
>   
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.

Cheers,
Daniel







> Thanks and regards,
> Bogdan
>
> Henning Westerholt wrote:
>   
>> On Friday 06 June 2008, Bogdan-Andrei Iancu wrote:
>>   
>>     
>>>> to be honest i don't think that introducing a new route that (could)
>>>> affect basically all modules two days before the freeze is a really good
>>>> idea.
>>>>       
>>>>         
>>> that's the whole idea with the freeze - code is committed into SVN and
>>> then there is a period of time to test (during the freeze). This the
>>> project policy.
>>> If you have a relevant technical opinion on this new functionality,
>>> please let me know. Otherwise, I do not see any issue here.
>>>     
>>>       
>> Hello Bogdan,
>>
>> i don't have unfortunally the necessary time today to review and test. With my 
>> current understanding i don't see any issues, otherwise i've already 
>> addressed them. 
>>
>>   
>>     
>>>> I had appreciated it if you've provided more informations about this
>>>> before the actual code has shown up, or at least do the commits a few
>>>> weeks in advance, to allow time for reviews and possible refinements.
>>>>       
>>>>         
>>> All of us are doing the best we can with the time we have. Maybe if you
>>> can give me the chance to post the description of this new commit, there
>>> will be no need for jumping into conclusions.
>>>     
>>>       
>> No offence, for sure. I really appreciate all the work that is done here of 
>> course.
>>
>>   
>>     
>>>>  Now i'm feeling a little bit rushed.
>>>>       
>>>>         
>>> about?
>>>     
>>>       
>> "Rushed" is probably a little bit to strong. I only think that this "last 
>> minute way" is a common pattern in this project how new features or changes 
>> gets introduced. A little bit more time to think about e.g. architecural 
>> issues or interface design would be really great, instead of postphone this 
>> to later releases. This is something that Dan also mentioned a few times in 
>> the past, i think. But i'm guilty in this area as anybody else. ;-)
>>
>> Should i convert the modules that i maintain to be able to use this new route?
>>
>> Cheers,
>>
>> Henning
>>
>>   
>>     
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>
>   

-- 
http://www.asipto.com




More information about the Devel mailing list