On Sat, 19 Nov 2011 18:41:21 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Sat, 19 Nov 2011 04:35:01 -0500 Mike Blumenkrantz <m...@zentific.com> said: > > > On Sat, 19 Nov 2011 18:25:28 +0900 > > Carsten Haitzler (The Rasterman) <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: > > > > > > 1. keep existing api's working and provide compatibility code inside edbus > > > connman to handle the new connman dbus protocol using the old api's > > > > > > OR > > > > > > 2. bump major .so version of edbus (specifically connman) AND place the > > > headers in a new folder so both old and new can be installed side-by-side > > > AND provide a new pc file with a -2 version. > > > > > > #2 is pretty much out of the question because econnman is tightly tied to > > > #the > > > rest of edbus and its version etc. and so would become an ugly exception > > > within the tree. > > > > > > so we need to retain compatibility so #1 is the only choice. > > > > > > > > I have actually talked with demarchi a bit, and I think we (and probably > > others) are in agreement that efl dbus stuff in general is pretty terrible. > > the base e_dbus library was written poorly wrt an actual api, and it's not > > much easier than just using regular dbus api (it's actually more difficult > > since you have to constantly reference the actual dbus api as well). This > > is a long-standing issue which I guess nobody noticed before efl 1.0 since > > not many people used or cared about the dbus stuff back then, but at this > > rate we are going to be stuck with The World's Worst DBus Integration (tm). > > > > We should probably focus some efforts on rewriting/upgrading it, and then > > bump the .so version and do a 2.0 release for just e_dbus. eet is already > > at v1.5 or whatever, so the argument of having different version numbers is > > not applicable here. > > for the future - that's definitely a topic on its own, but right now we have a > 1.1 release we can't do because its a definite abi break. i can ADD removed > api's back in and the abi change can be done by adding a new api with the new > params and keeeping the old with compat code. This seems reasonable, but I still stand by my opinion that the release should be slightly delayed. > > > For the 1.1 release, we need to roll back whatever API/ABI changes were made > > ASAP. After the 1.1 we can figure out what sort of changes we want to make. > > > > > > On the topic of the 1.1, I propose putting it off for at least another week. > > I've been steadily finding more and more bugs with group inherit in edje_cc, > > there have been a lot of lua commits coming in, other edje bugs are being > > found and fixed, and this econnman debacle is icing on the cake made of poor > > release material. > > -- > > Mike Blumenkrantz > > Zentific: Doctor recommended, mother approved. > > -- 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
