On Sun, 20 Nov 2011 21:03:00 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
> On Sun, Nov 20, 2011 at 4:48 PM, Lucas De Marchi > <lucas.demar...@profusion.mobi> wrote: > > 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). > > 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. > > 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. > > 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. We will never need ediskmanager. HAL is dead and not being updated, and the udisks people at least have a clue on how to write stable apis. > > 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. > -- 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
