On Sun, 20 Nov 2011 16:48:55 -0200 Lucas De Marchi <lucas.demar...@profusion.mobi> said:
> 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 there absolutely IS a reason to do it. when you produce a shared library you have an api and an abi. those are to not break unless you change major version (because the way linkers work at compile time the symlink to the major version is resolved and thus the binary is linked to the major version series, not minor versions). similar rules for compile-time. the application knows what version edbus is.. it's 1.x.x - that means the stable api released at the time. pkg-config tells it which version it is too - down to micro version. > >> 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. that wasn't there at 1.0 release. too late. it was a stable released api, you NOW are post-event marking it as unstable and breaking the api. too late. cat was out of the bag in janruary. > > 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! too bad. that's the cost of having a stable api. and edbus is a stable api. > > 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. tthey have no choice - because the REST of edbus upgrades and kills compatibility with it. as i said already - if you want to have it go keep breaking on its own - it should not be part of edbus. as long as it is, it stays and api stays stable until edbus 2.x - the connman api cannot be broken in edbus during 1.x - it can be extended, but not broken. what connman itself does is irrelevant. it is the job of edbus to provide a stable api. > > 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. they ARE claimed as stable as of edbus 1.0 - they are ALSO 1.0. they never had anything in their headers at 1.0 saying they were unstable etc. etc. - too late. the deal is done. > > 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. that is acceptable. we can mark the compat api's as deprecated, but until 2.x we cannot remove them (nor change the parameters they accept or their return values). :) > >> 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 we thought and agreed is not relevant to a library api and abi. a library api and abi are contracts. there is a contract between the library authors and the users of the library. by breaking the api or abi during a major version, you break the library side of the contract. it's unacceptable to do so. this isn't up for debate. these are actual contracts and agreements - just done in code. we cannot break our side of the contract. yes - sometimes it happens, and that's a bug to be rectified as soon as identified. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
