On Sun, Nov 20, 2011 at 2:18 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 19 Nov 2011 14:24:46 -0200 Lucas De Marchi > <lucas.demar...@profusion.mobi> said: > >> On Sat, Nov 19, 2011 at 7:25 AM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > while making connman work and improve is good... the edbus connman api has >> > been quite heavily broken now. >> > >> > this is now a blocker for efl 1.1 and we can't release until resolved. >> > here is what has happened: >> > >> > e_connman_service_apn_get() removed >> > e_connman_service_apn_set() removed >> > e_connman_service_ethernet_netmask_get() removed >> > e_connman_service_mnc_get() removed >> > e_connman_service_mode_get() removed >> > e_connman_service_security_get() api/abi break in parameters passed >> > e_connman_service_setup_required_get() removed >> > >> > we can't release with all these breaks. we are the ones providing an >> > advertised stable api to talk to connman. if connman itself breaks api, it >> > is our job to do either: >> >> I think there's not point in saying we implement a stable connman API. >> There's no way to check at runtime what is the version of ConnMan and >> doing all the work to be compatible with previous api is totally >> insane. > > then bump the major .so version and bump up the pc to be econnman-2.pc and > move > the headers to e_dbus-2/ instead of e_dbus-1/, make sure all the autofoo does > the right thing there in the build tree and make sure everyone knows it. the > problem is they kind of don't because its hidden inside a debus-1.x tarball > bundle. > > it's a pretty simple rule. you DON'T BREAK API OR ABI of a library within the > same major version.
My argument is that there's no reason to do this in a library. It's just there because there's currently no better way of doing it. The application using edbus won't know which version of the library it has to link to > >> E.g. the case a property changed from plain string to an array of >> strings. The natural name of the method for *future* versions cannot >> be used. > > after all the "we must release! release!" now this is not wanting to accept > the > responsibility of a release, and that is to keep compatibility. it is the That is the reason there's a flag saying what is and what isn't stable. > responsibility of the library writers to keep that compatibility - regardless > what the connman dbus protocol does. the protocol provided a single string > before, and now its an array - well my bet is in that array somewhere IS that > original string - so for compatibility you make the old api provide the "first > string in the array" for example. yes - it's a pain. yes. it's work. yes It doesn't work. It compiles, but it doesn't work. Unless you send a dbus message with one type of parameters, and on error you send another. Ugly! > connman dbus protocol changed - but that's not a pain you pass on to your api > users WITHOUT a big red blinking sign saying "look - it broke! don't upgrade > to > this unless you are prepared to do some porting work on your code". if e_dbus There is a blinking sign saying: this is unstable, don't upgrade unless you agree that this interface can change. > was 0.x.x - we could pass it off as "hell it's still getting its act together > so it has no clue what api to use". > >> As such the plan is to support the most recent versions packaged by >> distros, at least until the ConnMan API becomes more stable. This is >> why we added this in E_Connman.h: > > added... but it wasn't there on 1.0. 1.0 set up the playfield with an > advertisement of stability as long as its 1.x - every time api breaks you also My argument is: e_dbus is stable after 1.0 and there's no point in claiming e_dbus/*/ are stable. > drive people away - ESPECIALLY when the api breaks after a 1.x AND even more > when you break it withotut changing major version. > > i'm just saying - that by writing a library with a public and stable api it is > the responsibility of that author to not break api or abi during the lifetime > of that major version. doing so simple breaks the rules and conventions laid > down in unix and linux over decades that let people know that there was a > break. :) > >> #ifndef E_CONNMAN_I_KNOW_THIS_API_IS_SUBJECT_TO_CHANGE >> #error "E_Connman.h is an unstable API linked to upstream connman project" >> #endif >> >> >> However I really hope that at the time this happens we don't need this >> submodule anymore. Gustavo began to work on a tool to generate the C >> bindings (just like there's in, for example, qt and glib) to ease the >> use of dbus. Therefore we would not need this part of the lib and the >> application could directly use dbus. > > then maybe copy the existing connman code into e17's connman module and > replace > that code when codegen works. we can keep shipping the e_dbus connman forever > and not change its api or abi. :) This is the most sane thing I heard and I think it's the only way to improve connman module in E. Then I would really like to mark all the connman calls in e_dbus as deprecated. > >> For *this* release, it's sufficient to say we don't provide an stable API. > > unfortunately.. it's too late for that. it's a stable api because it was in > january when released as 1.0. this is the price u pay for making a stable > release that every distro and packager and user is demanding of us. In January we already know the connman API wasn't stable and we agreed the it could change. It was just not written nowhere. Now it is (well, it was before you reverted the patch). Lucas De Marchi ------------------------------------------------------------------------------ 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
