On Sat, 19 Nov 2011, Mike Blumenkrantz wrote:
> On Sat, 19 Nov 2011 10:40:52 +0100 (CET) > Vincent Torri <vto...@univ-evry.fr> wrote: > >> >> >> 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 >> > Yes, this is what I meant. well, in that case, that would not be an e_bus 2.0, but another library. 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
