[OpenSER-Devel] discussion: issues with local_route

[Daniel-Constantin Mierla]

On 06/24/08 15:48, Dan Pascu wrote:
> On Tuesday 24 June 2008, Daniel-Constantin Mierla wrote:
>   
>>>> Then I believe that not running openser will solve all bugs, nothing
>>>> will go wrong. This discussion goes aside the topic. If you consider
>>>> that doing operations to a message and affecting a completely
>>>> different message is not broken and critical because one has the
>>>> choice not to use those functions, then I cannot comment more on
>>>> this.
>>>>         
>> Either you don't understand what I am saying with above and below
>> phrases, or I don't understand what you are still asking.
>>     
>
> What I would like to see is a small sample of a script that does something 
> and the result is broken with the local_route inplace. The example you 
> gave with the m_dump inconsistency, is easily fixable IMO. Did you find 
> any other case that shows that the local_route breaks something and it 
> can't be fixed without a redesign?
>   
This is the final message on this discussion as we loop.

For me it is clear a major internal architecture change as none of my 
(and I spotted same for other parts) code was written with nested 
contexts in mind. I am not going now over all code to make a report, 
just because some code was released in the last minute without 
considering the impact on the rest of the application -- does not pay 
the effort.

In the first place, I asked to decide:
- unfreeze and allow time to review and properly design
- try fixes/propagation for local_route as per developer (enclose within 
defines and disable, as global approach, or each developers decides for 
its code).

I presented sustainable examples and reasons, those might be all or 
there might be lot more  - see dset.{c,h} all that code is not designed 
for nested contexts, time-related PVs have different results, a.s.o. 
Simply I don't have that time to prepare release and re-thinks code 
considered stable for ages.

>   
>> As said, let's move on and chose a direction. If for you solves the
>> accounting of self generated messages, for me breaks the
>> pseudo-variable engine, accounting, logging and routing. But we are not
>> alone here. I am going to fix what is broken in my side of code in any
>> of the variants.
>>     
>
> I'm perfectly happy with this approach. If everybody checks/fixes their 
> code,
Again, it is no time for me to check and test all the code I wrote in 8 
years, I am just going to disable it for local_route, and re-enable 
after the unfreeze, when I will take in consideration and analyze the 
new nested contexts architecture. I won't expose myself to stupid bugs 
reporting due to improper local_route-enabled code design and analysis.

Cheers,
Daniel


>  then before the release we can draw a line and if there are still 
> complaints of broken stuff we can ifdef and disable it. That's what I 
> asked from the beginning.
>
>   

-- 
http://www.asipto.com