On Mon, 21 Nov 2011 11:35:14 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Sun, 20 Nov 2011 21:03:00 -0200 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > > > What I tried to mean as well in README is that while libedbus.so is > > stable and there is an API for it, everything else in e_dbus/src/lib/ > > is convenience that is linked to the target service. As it should be. > > We just need these things due lack of code generator. > > unfortunately as of edbus 1.0 nothing in the README states connman (or any > other sub libs) was stable. > > > None of e_dbus/src/lib/* are abstraction layers in the sense of Ecore > > et al. They are direct 1:1 mapping to the service. They always should > > be. > > that doesn't matter. it's a library with an api and abi and it hasn't changed > major version thus must not break. there isn't something to debate here. these > are the rules of writing shared libraries. you don't get to just change them. > > > If one wants to create some enetwork that may talk to connman or > > networkmanager, then that's fine. Similar to ediskmanager to talk to > > hal or udisks. But that's not the case now. > > that doesn't change the fact that a shared library must not break api or abi > within the same major version. api/abi can be added in minor versions, but > nothing can be removed or changed. > > > ASAP I'll remove libeconnman.so it will cease to exist. A new library > > will be in, then it's not causing problems. > > > > So this "it's a release, you ask for it then you complain" is just > > *FUD*. Please stop. Don't flip things upside down. > > why the resistance to live up to the responsibilities of a library > author/maintainer? the responsibility is to maintain compatibility going > forward until a major version bump. if there is no will to do that then either > don't release a library. too late. it's released. this is something YOU > specifically wanted very much. > Can we just figure out a solution to this and stop the arguing over who is right or whatever? We supposedly have a release soon, and this appears to be a blocker. I propose that following this 1.1 release, we leave e_dbus and related libs as they are, starting a new library to do dbus serialization using eet and ecore-con. A code generator can be added on top of this, and that will provide the necessary infrastructure and scalability. The current e_dbus can be like embryo, which also will never reach 2.0. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
