Hi everybody,
also related to the new MI topic - as previously posted, there already an implementation for FIFO interface (FIFO <-> MI translation) - see http://openser.org/docs/modules/1.2.x/mi_fifo.html .
There are two hot topics I would like to address:
1) backward compatibility with all fifo implementation. The new fifo syntax is a bit simplify and changed in order to allow to be mapped over an "name = value" approach - see http://openser.org/docs/modules/1.2.x/mi_fifo.html#AEN40
The big difference is when it comes to values spreading across multiple lines (as the FIFO syntax is line orientated). In old implementation the line order was known by the functions implementing the external commands- lines with a single dot were used as end-markers for sets of line that should be interpreted as a single value. The MI interface is just doing translation (is not functionality aware) so a more coherent definition was needed - for multiple line value, quoted strings are used. This will break compatibility for functions using multiple line values like t_uac_dlg(). There are just a few functions, but they are.
2) for how long should we keep in parallel the two FIFO / UNIXSOCK implementations before dropping the old ones? I am a fan of a fast transition I would drop the old impls as soon as the new one offer the same functioanlity - this will accelerate the testing and migration process.
So the questions are - when to drop the old impls and how to deal with backward compatibilities (as MI will not be 100% compat with SEMS for example)
One solution (based on my opinions) - drop as soon as possible and use for backward compatibility a FIFO proxy to do translation between versions (for people interested in).
any other solutions are welcome for debate.
Regards, Bogdan
Bogdan-Andrei Iancu writes:
- for how long should we keep in parallel the two FIFO / UNIXSOCK
implementations before dropping the old ones? I am a fan of a fast transition I would drop the old impls as soon as the new one offer the same functioanlity - this will accelerate the testing and migration process.
since 1.1.2 will bring quite a lot of changes anyway, perhaps we could drop the old ones immediately. we need to bite the bullet at some time anyway.
So the questions are - when to drop the old impls and how to deal with backward compatibilities (as MI will not be 100% compat with SEMS for example)
since sems compatibility is very important and since we cannot change sems's socket interface, we have to provide backwards compatibility to it via tm module. i can be limited to unix socket only.
-- juha
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
- for how long should we keep in parallel the two FIFO / UNIXSOCK
implementations before dropping the old ones? I am a fan of a fast transition I would drop the old impls as soon as the new one offer the same functioanlity - this will accelerate the testing and migration process.
since 1.1.2 will bring quite a lot of changes anyway, perhaps we could drop the old ones immediately. we need to bite the bullet at some time anyway.
this is also my opinion - does anybody else have another one?
So the questions are - when to drop the old impls and how to deal with backward compatibilities (as MI will not be 100% compat with SEMS for example)
since sems compatibility is very important and since we cannot change sems's socket interface, we have to provide backwards compatibility to it via tm module. i can be limited to unix socket only.
AFAIK, the unixsock syntax is very similar to the FIFO one, so it might be affected by the transition to MI in the same way as FIFO and loose some backward compatibility. As the number of affected function is really small, my suggestion is to have a small unixsock/fifo proxy to translate from old version to new one (in case if we do not find a nicer way to ensure compat with serweb and sems).
regards, bogdan
Bogdan-Andrei Iancu writes:
As the number of affected function is really small, my suggestion is to have a small unixsock/fifo proxy to translate from old version to new one (in case if we do not find a nicer way to ensure compat with serweb and sems).
the proxy is fine as long as it is part of sems and not a separate process like fifo_server is. perhaps a filter would be a better term. in case of sems, also sip replies need to get there.
i'm not worried about serweb compatibility, because there is corresponding openser application in the works.
-- juha