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.

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

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Attachment: signature.asc
Description: PGP signature

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

Reply via email to