Hello VPP reviewers. When adding a comment to API flag day document, I have stumbled upon an idea, that is somewhat larger than the document itself. It has to do with a weaker form of VPP backward compatibility, specific to clients using Python API (PAPI).
Here is the relevant part of the comment [0]: I have realized, that although VPP binary API does not support optional arguments nor default values, PAPI does effectively support "false" values as default. Here, false value is zero, empty string, list of zero length, byte array (if size is fixed) initialized to each byte being zero, and so on. I believe it also extends to structured types, "false" means each field has the false value of its type. And I guess something reasonable also works for unions. This can give PAPI a limited form of forward compatibility. A client application using PAPI is forward compatible (conversely, VPP API change is backward compatible with respect to such client) iff the added fields, when called with the "false" value, do not change the behavior (compared to the previous VPP behavior where the fields were not defined). The larger idea is to change the current VPP API in a way that makes future API changes backward PAPI-compatible. This first change will be incompatible, so the subsequent changes do not have to be. Of course, my motivations are from CSIT committer point of view, and fairly selfish. Direct users of binary API will have no benefit from such a change, and I have no idea about users of jvpp or govpp. There are several approaches to making VPP backward PAPI-compatible, so I have prepared few examples. A typical way to add a new functionality to an existing API call currently looks like this [1]. The new field sw_if_index has a special value ~0, which restores the previous behavior. But that value is not "false", so this change is not backward PAPI-compatible. There are (at least) two ways the new functionality could have been handled in a backward PAPI-compatible way (from original call without sw_if_index). The "hard" way [2] is slightly easier to describe and implement, but there is also the "soft" way [3]. If VPP committers start encouraging such backward PAPI-compatible changes, it would look better if also the current calls were converted. Here is what would such a conversion look like, from current to hard [4] and from current to soft [5]. Both are PAPI-incompatible, but the soft only for sw_if_index 0, while the hard for all values except ~0. My personal preference is to recommend the hard way for new functionality, and the soft way for converting the existing functionality. This goal of this e-mail is to ask VPP committers which way they prefer. Of course, any other comments are also welcome. Vratko. [0] https://gerrit.fd.io/r/#/c/18356/2/docs/automating_vpp_api_flag_day.rst@94 [1] https://gerrit.fd.io/r/#/c/19233/1/src/vnet/interface.api [2] https://gerrit.fd.io/r/#/c/19235/3/src/vnet/interface.api [3] https://gerrit.fd.io/r/#/c/19234/2/src/vnet/interface.api [4] https://gerrit.fd.io/r/#/c/19199/3/src/vnet/interface.api [5] https://gerrit.fd.io/r/#/c/19198/3/src/vnet/interface.api
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12870): https://lists.fd.io/g/vpp-dev/message/12870 Mute This Topic: https://lists.fd.io/mt/31384190/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
