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