After digging into it further, I’d just like to point out that this is a significant breaking change that seems wholly unnecessary. The existing weight flag (0x01) could have just been deprecated by itself with no impact. There was no need to shift the other flags.
On closed systems running both OpenSIPS and the DB locally, in which the whole system is upgraded at once, this breaking change is not really an issue. However, in this era of cloud computing that is rarely the case anymore. In any distributed system where the DB is running separately from OpenSIPS, a breaking change like this requires a lot more work. Since it is not possible for OpenSIPS and the DB to upgrade at the exact same moment (a major point of distributed systems is to remove exactly these types of dependencies), the only recourse is a long process wherein we will have to: * create a new table for the new format * maintain both tables with double write until they are in sync * upgrade opensips * deprecate the old table I understand that this is a fairly standard upgrade path for a lot of DB changes, and I also understand that breaking changes are sometimes necessary to facilitate new functionality. But in this particular case, it does not seem justified to incur this extra cost on developers in order to recover that one bit flag for future use. In my opinion, the best practice in this case would have been to deprecate the weight flag only, without modifying the meaning of the other flags and causing the breaking change. After sufficient time the 0x01 flag could have been used for something else if needed, and in the meantime there were many bits left unused that should have been sufficient for future development, especially considering the relative lack of change in this area. What’s done is done in this case, but something to think about for future breaking changes, especially relating to the DB. Ben Newlin From: Users <users-boun...@lists.opensips.org> on behalf of Ben Newlin <ben.new...@genesys.com> Date: Friday, October 1, 2021 at 3:39 PM To: Liviu Chircu <li...@opensips.org>, OpenSIPS users mailling list <users@lists.opensips.org> Subject: Re: [OpenSIPS-Users] DROUTING module flag changes Liviu, Thank you, I do see it there. So it is confirmed the flags have shifted. It appears the module documentation is still in need of some updates to reflect this change for carriers. Ben Newlin From: Liviu Chircu <li...@opensips.org> Date: Friday, October 1, 2021 at 3:35 PM To: OpenSIPS users mailling list <users@lists.opensips.org>, Ben Newlin <ben.new...@genesys.com> Subject: Re: [OpenSIPS-Users] DROUTING module flag changes On 01.10.2021 21:34, Ben Newlin wrote: Can anyone clarify the expected behavior here? Were the values for the flags column changed as part of removing the weight flag? Hey Ben, I believe you're referring to a change from 3.1, where the carrier "W" flag was removed & all other flags were shifted. This change in behavior is documented in the migration page [1]. [1]: https://opensips.org/Documentation/Migration-3-0-0-to-3-1-0#toc9<https://opensips.org/Documentation/Migration-3-0-0-to-3-1-0#toc9> -- Liviu Chircu www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> | www.opensips-solutions.com<http://www.opensips-solutions.com> OpenSIPS eBootcamp 2021: www.opensips.org/training<http://www.opensips.org/training>
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
