[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] DBUS Take 2
On 10/23/06, Brian Mattern <firstname.lastname@example.org> wrote:
After spending some quality time with ecore_dbus and realizing how far
from complete it is, I started to wonder "Why the hell do we have (the
start of) a full reimplementation of dbus?"
The low-level dbus API was designed to be as framework agnostic as
possible. Shouldn't we just be wrapping dbus in an efl api (that handles
hooking into the ecore main loop, etc) ala the glib/qt bindings?
My fault, i coded it.
When i started coding the ecore dbus my plan was to make it in fact
another binding, like qt or gtk, cant recall now why i didnt do it
that way, i think there were some issues, but as i said i cant
I'm starting to piece together some basic test code to this end, but
just wanted to ask why this wasn't done in the first place? Was there a
specific obstacle to integrating the two (haven't seen any yet, myself)?
Or was this just an exercise in re-implementing a large body of code
from a less-than-spectacularly documented spec? :)
Well i used the specs to code it, the protocol isnt hard, so i thought
it would be better to have an implementation of the dbus protocol on
the e side :) smaller and simpler.
Anyway, if I get this working, I'd prefer to just have an e_dbus lib
that lives outside of ecore (either in a git repo alongside the other
dbus bindings, or elsewhere in e cvs).
i agree, ecore_dbus is a piece of code im not touching anymore, i
think sebastid and you have make it a better lib, enough for
basic/common protocol interaction, but looks like you have more plans
with it so better integrating into the main dbus lib is a better
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
enlightenment-devel mailing list