[OpenSER-Devel] SF.net SVN: openser: [3156] trunk/modules/permissions/mi.c

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Nov 20 18:38:47 UTC 2007


Hi Henning,

Henning Westerholt wrote:
> On Monday 19 November 2007, Bogdan-Andrei Iancu wrote:
>   
>> To solve this potential problem without any change in the MI interface
>> and without no runtime penalties (strlen), I just added a small macro
>> MI_SSTR (MI  Static String) to compute the len of a static string at
>> compile time.
>>
>> With it, instead of having:
>>     add_mi_node_child( rpl, 0, "Server", 6,......
>> you can do:
>>     add_mi_node_child( rpl, 0, MI_SSTR("Server"),.....
>>
>> As a POC, I did the changes on the MI core functions and the permission
>> module.
>>     
>
> Bogdan,
>
> this is exactly the type of interface that makes programming and debugging in 
> OpenSER for me more hard than necessary. I could tell you a story from a 
> recent bug caused of the non-type safty of the str_init macro, or explain my 
> understanding of "good" API design, but as you said, lets try to don't get 
> religious about this issues. I really like the good performance of the 
> server, but i don't see a compelling need for high performance FIFO commands.
>   
nobody said programming is easy :d, but in my opinion the software we 
are doing has as main purpose to do a job as best possible and not to be 
an example of structured code, APIs or easy to work with - all these 
come on the second step.
Al so far decisions where based on this facts - to get a software to do 
its job in an efficient way. If would targeted a nice design, we could 
avoid the roughness of C and go for JAVA which is a nice language to 
write proper structured code.

anyhow, it is not only about FIFO, but for all MI and later this started 
to be more and more used. Secondly I'm not in favour to introduce any 
kind of penalty if can be avoided.
> Anyway, i want to second the objections that Dan raised in his mails. I see a 
> need to discuss this change more thoroughly, as this is the type of interfaces 
> that i don't like to see that much in new code.
>   
The interface was not changed - it was inserted an helper macro to 
minimize as much as possible the probability to insert a bug due bogus 
length.
> I don't want to waste my and your time now to discuss this issues, and i also 
> think we're currently to late in the release cycle for an introduction of a 
> new interface to the core.
Again there is not a new interface, nor a change in the interface.
>  So i would like to ask you to revert the addition 
> of the new macro and the changes in the mi core and permission module.
>   
I prefer not to - the purpose of this change was to fix bugs and avoid 
inserting new bugs. I do not think reverting a bug (or possible bug) fix 
makes any sense.
> We're releasing 1.3 in about two weeks, and then we can all start hacking 
> again, i'm counting the days too.. ;-)
>   
yes, but till then the priority 1 is to have a code as safer as possible 
and as bug-free as possible. This is my major concern for the moment,

Best regards,
Bogdan
> Thank you and best regards,
>
> Henning
>
>   




More information about the Devel mailing list