3 ms·
> Is that sarcasm, or you don't know what dbus is used for? I know what it's used for in the desktop application space; but you might want to ask the authors o
by byuu 12y ago
> Is that sarcasm, or you don't know what dbus is used for?
I know what it's used for in the desktop application space; but you might want to ask the authors of Xfce components like Mousepad that make their software rely on it for simple tasks like reusing an existing window when opening a file. Because I'd sure like to be able to run my Xfce desktop with D-Bus off in FreeBSD.
"D-Bus is a message bus system, a simple way for applications to talk to one another."
With shared memory (IPC) or sockets (RPC), applications can talk to each other.
Yes, D-Bus gives you an API interface for this (though I personally can't stand it); which apparently comes with tremendous overhead, if the linked article is to be believed.
Yes, with raw memory/sockets, you have to do the queue work yourself. But that's CS101 stuff; you shouldn't touch IPC if you can't implement a simple shared queue.
For most use cases, D-Bus is like using a jackhammer to nail in drywall.
"In addition to interprocess communication ... it makes it simple and reliable to code a "single instance" application or daemon"
Again, very easy with shared memory and a semaphore. If your attempt to open the semaphore fails, you create it and become the daemon. When the daemon closes, you delete the semaphore. When a second instance opens and connects to the semaphonre, and then shared memory, then it writes the command-line arguments into the queue, and the daemon handles it. Voila, "single instance" application or daemon.
"and to launch applications and daemons on demand when their services are needed"
And this would be a more complex use case that would be harder to solve. It's also a much less common use case. I don't really feel it's directly related to basic IPC, it's D-Bus trying to solve multiple problems at the same time.
I'd rather follow the Unix way and split that into a separate component, perhaps built on top of the IPC protocol.
- coldtea 12y ago>With shared memory (IPC) or sockets (RPC), applications can talk to each other. The whole idea is the "standard" part, not merely the "talk to each other part".
- jude- 12y agoI think what you're looking for is API standardization? If so, dbus does nothing more to help you than POSIX IPC, since each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects. Dbus is basically a way to do library calls across address spaces--it doesn't help me write programs that are loosely-coupled to one another.
- coldtea 12y agoNo, looking for a standard message bus that works across applications. I don't mind that "each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects", as that's the whole point.
- byuu 12y agoIf you don't know the API the application uses, you can't speak with it anyway. D-bus or not. If you want to talk to an entirely separate application, use a header for that application with its IPC/RPC functions defined in it. That's the same thing you'd do with or without D-bus. All D-bus gets you is an official version of the header I spoke of. Along with so much overhead that you can't use it for any kind of media streaming, apparently. And now they want kdbus; and I definitely don't want their code in my BSD kernel.