GNOME Bugzilla – Bug 164652
platform bindings rules clarifications
Last modified: 2005-03-03 19:09:17 UTC
The platform bindings rules page (http://developer.gnome.org/dotplan/bindings/rules.html) needs to be clarified in regards to API and ABI requirements. The section on "API/ABI freeze" doesn't actually specify any rules on ABI compatibilities, only on API compatibilities. Additionally, ABI is not defined - is it ABI across the entire platform, or against a undefined version of the binding's runtime, or what? ABI is generally clearly understood in terms of C/C++ apps, but it is not so clearly understood in terms of Perl/Python/Java/etc. Additionally, there is no description of the intention of the rules. This is rather vital - in a court of law, for example, even when a loophole or whatnot is found in a contract/license, judges will often base their decision on the spirit of the document declared in its preamble. If the spirit of the API/ABI was defined on the bindings rules the omitted details would be less important. Basically, is the purpose of the bindings to allow an ISV to target a specific version of GNOME, a specific version of GNOME or higher, or a specific version of GNOME *and* a specific version of the interpreter/runtime related to the binding? This needs to be clearly defined both for binding developers to understand the specific rules they must follow, for packagers to know how to handle any relevant backwards compatibility issues, and for ISVs to make informed decisions as to whether they should use a particular binding or not. If it is determined that the runtime for a binding is to be undefined, clearly state that as part of the ABI rules. Basically just make sure that everyone reading the rules page gets the same idea of the purpose of the bindings and exact meanings of API/ABI stability requirements and how those affect each binding present. If nothing else, that'll shut me up on the desktop-devel lists, and I know you guys are about ready to fly to Ann Arbor and stab me. ~_^
> The section on "API/ABI freeze" doesn't actually specify any rules on ABI > compatibilities, only on API compatibilities We can chage API to API/ABI there. It's fairly clear that they are often the same thing. > Additionally, ABI is not defined - is it ABI across the entire platform, or > against a undefined version of the binding's runtime, or what? We don't specify any ABI rules for the runtime. The bindings do not seek to change the runtime. They do seek to stop bindings modules from doing things that would break applications. If the runtime breaks an application then that's the runtime's problem. Of course, applications and bindings should do what they can to avoid such problems, when there is something that they can do. > If it is determined that the runtime for a binding is to be undefined, clearly > state that as part of the ABI rules. OK. That might deal with most of your issues. > ABI is generally clearly understood in terms of C/C++ apps, No, I think people are confused there too, and quite rightly have various definitions. That's why we have ABI rules for the Platform as well as Bindings. > but it is not so > clearly understood in terms of Perl/Python/Java/etc. That's why we have these generic Bindings rules. > Additionally, there is no description of the intention of the rules. Nonsense. This is the stated intention: " # Do not break ABI. For instance, if an application uses 2.6.0, installing 2.6.1 should not intentionally break that already-installed application. # Do not break API. For instance, you should not break application builds. If an application built with 2.6.0, then it should build with 2.6.1. # You may not add API in the stable (2.6.x, for instance) phase. You must wait until the next schedule to add API. This means that there are not multiple versions of the API, so it is simpler for developers to aim at a particular API version. Remember, it's not a problem if you must wait to add API, because you must only wait <6 months until the next stable release. For instance, GTK+ 2.4 adds API compared to GTK+ 2.2. " Another unstated aim for me is that software developers have less combinations of API versions to target, so they have less decisions to make, and less variety of platforms to adapt to. > Basically, is the purpose of the bindings to allow an ISV to target a specific > version of GNOME, a specific version of GNOME or higher, or a specific version > of GNOME *and* a specific version of the interpreter/runtime related to the > binding? None of the above. It allows ISVs to target specific ABIs (specific or higher). For instance, people can target the GTK+ 2.0 ABI (Which has versions 2.0, 2.2, 2.4, and 2.6 so far), but they can not expect their application to work if only GTK+ 3.0 is installed. It might not have the intention that you want (I think, that application binarys can be on any system anywhere without ever installing dependencies or changing the underlying platform, and that ABIs never have new incompatible parallel-installable versions, because you like stagnation somehow) But I know of no OS that offers that, and I don't see the point in demanding the (so far) impossible.
> Nonsense. This is the stated intention Please ignore the 3rd point there.
"Another unstated aim for me is that software developers have less combinations of API versions to target, so they have less decisions to make, and less variety of platforms to adapt to. " One of the biggest points of my complaint is that by not specifying the runtime version you *increase* the variety of platforms a developer has to target. (that's been discussed to death on the list, won't repeat the arguments yet again here.) "It might not have the intention that you want (I think, that application binarys can be on any system anywhere without ever installing dependencies or changing the underlying platform, and that ABIs never have new incompatible parallel-installable versions, because you like stagnation somehow)" That is so far from the truth I'm actually stunned... if after the entire discussion that is the meaning you have interpreted, then I give up entirely. Thanks for clarifying the other issues, though, I really do appreciate that.
I added some clarifications: - API means "API and ABI". - say that these are not rules for the runtime, but say that good runtimes follow similar rules, to solve the same problems. - say that parallel-installed versions of one runtime should have associated parallel-installed bindings.