I never had dbus crashing anytime.. Regarding communication channels - there are two types in dbus - one is system and other is userland.. So dbus provided something for userland apps which could not use IPC for some reason. Another main reason as pointed above, it is general pub/sub system - which wasn't there before, and it is quite generic in that publishing to an interface works(need not know underlying stuff). Regarding bad experiences with dbus, it is the application's fault. If app is having problem with dbus, then compile that app without dbus. If that doesnt work then ditch that application. (send flame mail to app creator :) if you are over pissed) On Fri, Dec 4, 2009 at 2:45 AM, David Rosenstrauch <darose@xxxxxxxxxx>wrote: > On 12/03/2009 12:29 PM, Aaron Griffin wrote: > >> Mechanisms have existed for like 20 years before dbus to communicate >> with other programs. dbus is just another way to do it that has a >> smell of "architecture astronomy" - as if they all scoffed at the >> actual ways to do IPC on various Unicies and said "Oh, I can design >> better". >> >> That's why I dislike it. >> > > I'll preface this by right up front saying that my knowledge of dbus is > actually pretty limited. So forgive me if I'm off-base in my comments. > > But frankly, I didn't think the *intent* behind dbus was as a replacement > for IPC. As I understood it, dbus was intended to be a system-wide message > bus - i.e., a very generic pub/sub type of system that could be used by any > component in the system. Some components would publish messages of a > particular, and other components would get notified about messages of a type > they're interested in and react to them. > > Makes some sense to me to do things this way, as then you can just have a > single, standard system-wide daemon that every app interacts with in the > same way, rather than force each app to reinvent the wheel and implement > their own solution. > > DR >
