Hi, hm, the discussion becomes even longer than the huge changset.
My fundamental consideration is that we use interfaces to coordinate our work. Ideally those interfaces should be designed perfectly, but in practice forecasts are tricky, especially if they concern the future. So it is helpful to have a meta interface which governs how changes of the programming interfaces shall happen and who is in charge to adapt existing code to those changes. We are now discussing this meta interface. My idea of it is: * Never break the API (source code compatibility) of a library. If it's broken, then the library can as well get a new name. This is quite a necessity for all distro maintainers, who have to build software which they do not know in depth. It is also a courtesy towards the developers of applications who would else be forced to change their code without own motivation. * Try hard to keep the ABI usable for old programs which have been compiled to use an older version of the dynamic library. This is a courtesy towards the users of applications. They can carry them to more modern versions of their operating system without the need for recompilation (which might be not trivial). * Design the API/ABI for being expandable without conflicting with the first two rules. To our luck there is a broad trail of other software which already relies on the opportunity to attach new members to structs without disturbing the older members. This ideal is quite common in the plumbing layers of GNU/Linux. It is much less visible in its desktop world. I blame the short breath of GNU/Linux GUI developers on that porcellain fragility. All three big burn GUIs are effectively orphaned currently, while two of the three burn backends are well alive. ------------------------------------------------------------------------ It seems that i forgot to consider language bindings in my proposal. I will explore this aspect in the next days. (Expect questions.) Have a nice day :) Thomas
