On Sat, 19 Nov 2011 10:46:53 +0100 (CET) Vincent Torri <vto...@univ-evry.fr> wrote:
> > > 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 The point of my statement was that the current form of e_dbus is insufficient. Whatever steps are necessary to fix it and make it more usable should be taken. -- 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
