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

Daniel-Constantin Mierla miconda at gmail.com
Fri Jun 6 23:27:08 CEST 2008 

Hello,

On 06/06/08 22:55, Bogdan-Andrei Iancu wrote:
> Hi Daniel,
>
> Just to cut to the chase (time is precious ;) ):
>
>    1) discussions are welcomed, but before doing it we should have 
> first a fully understand of the subject (technically) and second, we 
> should have a pertinent understanding of the implementation
>
>    2) my impression is that you got a wrong idea about the purpose of 
> this new route (based on your technical arguments form the previous 
> email)

The purpose of the route is good, but the current code does not 
implement that. I think I explained a lot on my previous email.

>
>    3) we should focus more a the creative side of the work, rather on 
> bullshit-bing discussions like : how long before a freeze a major 
> commit should be allowed? how do I define a major commit ? etcc....

Just a typo, because it repeats -- it is bullshit-bingo.
http://www.bullshitbingo.net/cards/bullshit/

And I can call it because open source project and collaborative 
environment means something else. It is waste of the time if everybody 
plays own rules and goes in different directions, without considering 
the others. I see no reason why the developer of benchmark or other 
modules that got enabled for local_route not to revert as they had no 
chance to see the purpose and how that can affect the code they have to 
maintain.

Cheers,
Daniel


>
> Otherwise we are just wasting our time.
>
>
> Regards,
> Bogdan
>
> PS: if someone does not know how to play "bullshit-bing" game, let me 
> know - it is fine :D
>
>
> Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> On 06/06/08 21:39, Bogdan-Andrei Iancu wrote:
>>> Hi Daniel,
>>>
>>> We do not have to overlook the fact that an open source project is a 
>>> result of common contributions from multiple people. So, it is about 
>>> more than one person and we should not have a selfish view on the 
>>> matter - maybe some new code does not solve anything for you, but 
>>> certainly it does for other people. As I detailed in the email 
>>> announcing this functionality, this new code addresses the multiple 
>>> needs, coming from multiple people.
>>>
>>> New functionalities and features are among the main definitions of 
>>> the project, so any new commit, even before last minute is welcome - 
>>> as time as it does not break anything.
>>>
>>> With the risk of repeating myslef, if you have some technical issue 
>>> with this new code, I'm open to discussions. But please, before 
>>> that, try to understand what this new functionality is about - if 
>>> you have un-clarities please let me how, I will work them out with 
>>> you. Maybe diving a bit into the code will help you formulating an 
>>> opinion.
>>>
>>> But just to bring more light (as I see it is a big misunderstanding 
>>> on what this route is about) : This route is TM specific and is used 
>>> only for the stateful requests that are internally generated by TM 
>>> (with no UAS side); it has nothing to do with the core or with any 
>>> reply or anything else; it provides a mechanism to catch in script 
>>> requests generated by openser, requests which otherwise will be 
>>> totally transparent - for more, again, please refer to the info 
>>> email I previously sent.
>>>
>>> Opinions may vary, but in a truly fair and respectful environment, 
>>> applying labels to other people work just because you personally do 
>>> not agree or find useful is not constructive at all.
>> repeating myself again, I didn't claim at all the current code is not 
>> good at all, and I haven't labeled anyone. My answer to Henning was 
>> to show that it is not nailed down that last minute commits are not 
>> to be discussed just that we meet the freezing deadline and that is, 
>> we have to live with them (again, that is at general view, not really 
>> tied to this case)
>>
>>
>> I just said that a proper discussion would have solved lot more. The 
>> current code is not really bound to TM, in the future such route can 
>> be added, as you wrote in the announcement, all bindings to TM are 
>> going to be implemented -- that is the right time for such route. 
>> Now, the same code can be easily moved a bit around to bring more 
>> functionality and flexibility.
>>
>> Cheers,
>> Daniel
>>
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Daniel-Constantin Mierla wrote:
>>>> 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

More information about the Devel mailing list