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

[Bogdan-Andrei Iancu]

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)

    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....

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
>>>>
>>>>   
>>>
>>
>