On Sat, 13 Mar 2004 15:54:24 +0100 Michel Briand <[EMAIL PROTECTED]> babbled:
> Hello,
>
> I studied DBUS and it seems to be somewhat interesting. A few years ago
and immensely inefficient in many ways - for 2 apps to talk they need to send to
the dbus borker then it sends out again - this means 3 processes involved in a
simple message from A to B and the kernel invovled twice, memcopies of the ipc
data all over the place and context switching hell. sure the idea is cool- the
right concept. implementation is not what its cracked up to be. the dbus crowd
would have u think its the panacea for all - people who know better just laugh
and get on with work.
> I worked on a big software using COM/DCOM and I discovered CORBA also.
> But those days I prefer very simple and slim sofware solutions ;-). The
> GNOME and KDE overweighted systems are a very PAIN in the ### as you
> used to say.
it is! :)
> Thus if you think there is a clever need for Ecore to exchange
> messages/activations with remote processes I would like to help you
> implement DBUS support in Ecore.
theres 2 choices here. 1. ecore_dbus module for apps to use dbus directly -
sure. possible. i see no reason why not, but imho i think dbus has something to
be desired.
> But: we have to make things very clear at the beginning. What are the
> goals ? Copy/paste involving processes running on the same display but
> on different hosts ? I don't know if there is an existent solution.
> Communication between "base level - script or daemon" world to "hight
> level - well integrated gui" world ? (I've seen Hal specs too...).
i was envisaging more a dbus gateway daemon. it basically listens to dbus and
talks dbus on one side, and on the other talks E-IPC. apps just use E-IPC to
talk to it or eachother as they see fit. E-IPc works. its small. it's lean and
an transport data very similarly to dbus if you use eet to pack/unpack data
structs into binary lumps. all the nuts and bolts are there, tested and work.
the problem here is we add ANOTHER process int he path between dbus and e-ipc
apps. e-ipc apps will be much more efficient amongst themselves as its direct
point to point communication. but if we do a lot of dbus interaction - this
starts to look nasty.
anyway - i think this needs discussion... what do people think? if we did have a
dbus wrapper it'd have to handle data struct packing/unpacking form the dbus
encapsulation protocol. its a waste to have every app do this itself.
> BTW is there an EDGE user manual around ?
>
> Best regards,
>
> Michel / Couannette
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
