On Sat, 19 Nov 2011, Mike Blumenkrantz 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). > > 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. better writing an ebus lib like raster told me, not using dbus but our own implementation. It seems (i'm not an expert, Gustavo told me that iirc) that using dbus means translating back and forth messages which is useless. Also, using eet would be better. Vincent ------------------------------------------------------------------------------ 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
