Carsten Haitzler (The Rasterman) wrote: > 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 > > >
I hope you don't mind me asking about this, I'm not much of a programmer so I don't really know much about IPC. I did do a little reading about dbus a while back, and what I thought I understood is that there are two parts of dbus: the dbus protocol, and the dbus daemon. I think that two apps can use the dbus protocol without involving the daemon and thereby incurring extra overhead. The main purpose of the daemon seems to be for sending a message to multiple programs. So here's my question: assuming that the above is correct, how does dbus compare to e-ipc if you aren't involving the dbus daemon? Thanks for all of the awesome work you do, Christopher ------------------------------------------------------- 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
