[E-devel] DBUS Take 2

[Brian M. <bri...@gm...>]

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?

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? :)

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

rephorm