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 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. ------------------------------------------------------------------------------ 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
