Hi everybody,
with the adding of asynchronous reply feature in MI and MI_FIFO implementation, the transition to MI was completed - all former FIFO functions (old implementation) were ported to MI. Also all FIFO capabilities were also ported to the new MI_FIFO module.
so, currently there are two FIFO implementations: - the old one, directly in core. - the new one, based on MI interface.
the old implementation is obsolete (all external management will be done via MI) , so, at some point, it will be removed from OpenSER in order to maintain consistency and avoid confusion between the two implementations (as they are equivalent from user point of view - at the moment, at least).
my question is when to drop the old implementation? my personal preference will be do doing ASAP as : 1) no functionality is lost 2) avoid confusion among users and the explanation overhead 3) it will force the testing of the new FIFO and MI implementation, which will shorter the way to a stable form.
I would like to know also some other opinions.
regards, bogdan
Bogdan-Andrei Iancu writes:
my question is when to drop the old implementation? my personal preference will be do doing ASAP as : 1) no functionality is lost 2) avoid confusion among users and the explanation overhead 3) it will force the testing of the new FIFO and MI implementation, which will shorter the way to a stable form.
bogdan,
in my opinion you can drop old fifo implementation immediately (although i haven't had yet time to test mi t_uac_dlg with xml-rpc).
i guess the next thing is mi implementation of unix socket interface, which then requires openser version of sems unix socket interface.
-- juha
IMO dropping old FIFO now is fine.
regards klaus
Bogdan-Andrei Iancu wrote:
Hi everybody,
with the adding of asynchronous reply feature in MI and MI_FIFO implementation, the transition to MI was completed - all former FIFO functions (old implementation) were ported to MI. Also all FIFO capabilities were also ported to the new MI_FIFO module.
so, currently there are two FIFO implementations:
- the old one, directly in core.
- the new one, based on MI interface.
the old implementation is obsolete (all external management will be done via MI) , so, at some point, it will be removed from OpenSER in order to maintain consistency and avoid confusion between the two implementations (as they are equivalent from user point of view - at the moment, at least).
my question is when to drop the old implementation? my personal preference will be do doing ASAP as :
- no functionality is lost
- avoid confusion among users and the explanation overhead
- it will force the testing of the new FIFO and MI implementation,
which will shorter the way to a stable form.
I would like to know also some other opinions.
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi everybody,
are any other opinions on this matter? otherwise I will proceed with removing the old FIFO implementation.
regards, bogdan
Klaus Darilion wrote:
IMO dropping old FIFO now is fine.
regards klaus
Bogdan-Andrei Iancu wrote:
Hi everybody,
with the adding of asynchronous reply feature in MI and MI_FIFO implementation, the transition to MI was completed - all former FIFO functions (old implementation) were ported to MI. Also all FIFO capabilities were also ported to the new MI_FIFO module.
so, currently there are two FIFO implementations:
- the old one, directly in core.
- the new one, based on MI interface.
the old implementation is obsolete (all external management will be done via MI) , so, at some point, it will be removed from OpenSER in order to maintain consistency and avoid confusion between the two implementations (as they are equivalent from user point of view - at the moment, at least).
my question is when to drop the old implementation? my personal preference will be do doing ASAP as :
- no functionality is lost
- avoid confusion among users and the explanation overhead
- it will force the testing of the new FIFO and MI
implementation, which will shorter the way to a stable form.
I would like to know also some other opinions.
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Go for it. I'm all for keeping things simple...
cheers ----- Original Message ----- From: Bogdan-Andrei Iancu bogdan@voice-system.ro To: Klaus Darilion klaus.mailinglists@pernau.at Cc: devel devel@openser.org, users openser.org users@openser.org Sent: Thursday, December 14, 2006 4:18:37 AM GMT-0600 Subject: [Devel] Re: [Users] Request for Discussion: MI and FIFO
Hi everybody,
are any other opinions on this matter? otherwise I will proceed with removing the old FIFO implementation.
regards, bogdan
Klaus Darilion wrote:
IMO dropping old FIFO now is fine.
regards klaus
Bogdan-Andrei Iancu wrote:
Hi everybody,
with the adding of asynchronous reply feature in MI and MI_FIFO implementation, the transition to MI was completed - all former FIFO functions (old implementation) were ported to MI. Also all FIFO capabilities were also ported to the new MI_FIFO module.
so, currently there are two FIFO implementations:
- the old one, directly in core.
- the new one, based on MI interface.
the old implementation is obsolete (all external management will be done via MI) , so, at some point, it will be removed from OpenSER in order to maintain consistency and avoid confusion between the two implementations (as they are equivalent from user point of view - at the moment, at least).
my question is when to drop the old implementation? my personal preference will be do doing ASAP as :
- no functionality is lost
- avoid confusion among users and the explanation overhead
- it will force the testing of the new FIFO and MI
implementation, which will shorter the way to a stable form.
I would like to know also some other opinions.
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
-
Bogdan-Andrei Iancu -
jh＠tutpro.com -
Klaus Darilion -
Mahesh Paolini-Subramanya