On Sat, 19 Nov 2011 19:42:30 +1000 David Seikel <onef...@gmail.com> wrote:
> On Sat, 19 Nov 2011 04:35:01 -0500 Mike Blumenkrantz > <m...@zentific.com> wrote: > > > 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). > > Actually, our dbus is one of the few that did not crash the app when > that bleeding edge app I have used to take out most dbus using apps > every now and then. That nasty app seems to have had that problem > fixed now, but still it showed there was some robustness in e-dbus. Robustness isn't the issue here, and the reason for that robustness is actually just the fact that we use libdbus, which IS very robust. > > > 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, > > Erm, most of those lua commits have been documentation or comments. > -- 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
