On Sun, 20 Nov 2011 21:52:31 -0500 Mike Blumenkrantz <m...@zentific.com> said:
> On Mon, 21 Nov 2011 11:35:14 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Sun, 20 Nov 2011 21:03:00 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > > What I tried to mean as well in README is that while libedbus.so is > > > stable and there is an API for it, everything else in e_dbus/src/lib/ > > > is convenience that is linked to the target service. As it should be. > > > We just need these things due lack of code generator. > > > > unfortunately as of edbus 1.0 nothing in the README states connman (or any > > other sub libs) was stable. > > > > > None of e_dbus/src/lib/* are abstraction layers in the sense of Ecore > > > et al. They are direct 1:1 mapping to the service. They always should > > > be. > > > > that doesn't matter. it's a library with an api and abi and it hasn't > > changed major version thus must not break. there isn't something to debate > > here. these are the rules of writing shared libraries. you don't get to > > just change them. > > > > > If one wants to create some enetwork that may talk to connman or > > > networkmanager, then that's fine. Similar to ediskmanager to talk to > > > hal or udisks. But that's not the case now. > > > > that doesn't change the fact that a shared library must not break api or abi > > within the same major version. api/abi can be added in minor versions, but > > nothing can be removed or changed. > > > > > ASAP I'll remove libeconnman.so it will cease to exist. A new library > > > will be in, then it's not causing problems. > > > > > > So this "it's a release, you ask for it then you complain" is just > > > *FUD*. Please stop. Don't flip things upside down. > > > > why the resistance to live up to the responsibilities of a library > > author/maintainer? the responsibility is to maintain compatibility going > > forward until a major version bump. if there is no will to do that then > > either don't release a library. too late. it's released. this is something > > YOU specifically wanted very much. > > > Can we just figure out a solution to this and stop the arguing over who is > right or whatever? We supposedly have a release soon, and this appears to be a > blocker. i've offered the solutions: 1. remove econnman from edbus entirely (put it into e17). 2. change major version of econnman and put headers into edbus-2 dir and change econnman.pc to be econnman-2.pc 3. have compat api's and make them work (i've added them - i haven't made them work). > I propose that following this 1.1 release, we leave e_dbus and related libs as > they are, starting a new library to do dbus serialization using eet and > ecore-con. A code generator can be added on top of this, and that will provide no - that wouldnt be compatible with dbus. dbus has a specific socket setup (anonymous sockets on linux normally which ecore_con can do) AND a spefific wire protocol for encoding data. if we don't deal with that encoding, then it isn't dbus. :) > the necessary infrastructure and scalability. The current e_dbus can be like > embryo, which also will never reach 2.0. > > -- > Mike Blumenkrantz > Zentific: Doctor recommended, mother approved. > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
