2 ms·

There are cases where you want to be notified when an event occurs or the success of your application's action (in more detail than the error codes from a write

There are cases where you want to be notified when an event occurs or the success of your application's action (in more detail than the error codes from a write(2) to a FD). You can solve the problem by using socket FDs, but you have to roll your own format for registration, communication, error checking, making sure the appropriate applications can read, etc. I think many developers would prefer using DBus as an abstraction for these types of problems.

moe 12y ago
Why not a library that speaks a simple[1] line based protocol over pipes and/or sockets? Or even just plain old files? That's how unix used to work before the desktop people took over. [1] Yes, DBus is "sort of" line based. But from all I've heard it's the opposite of simple and... well, let's just say people don't seem to have much good to say about it.
- swhipple 12y ago
  It's true that DBus is somewhat of a complex solution if you have a simple enough use case, and I think most of the criticism is the documentation rather than the design (or, rather, criticism of the design is mostly that it isn't Unix-like). But having a daemon that relays your messages to other applications based on a standardized protocol has some merit of its own, even if it isn't strictly Unix-like. I might have some bias, since I think the Unix-way is oversimplified for some problems, even though there are often ways to make it work.
  - moe 12y ago
    But having a daemon that relays your messages I agree, and I'm not opposed to the idea of a daemon. DBus just seems to be (from my perception) rather poorly designed on every level. And the more pervasive it becomes the more of its bad design bleeds into more or less unrelated other software packages. the Unix-way is oversimplified for some problems The unix-way of course has limits, but it's usually worth to explore it as far as possible and only then divert to more baroque designs. In the majority of cases you'll find that pure, file-based approaches are a lot more elegant, efficient, discoverable and debuggable than the alternatives (see e.g. qmail vs postfix, or runit). There's a lot to be said for being able to use the standard unix cutlery to inspect and interact with the guts of your application. Imagine DBus was just a directory with one or two files per pid. Imagine you could read past messages with 'cat', follow them with 'tail' and inject new ones with 'echo'.
deong 12y ago
The kernel has had inotify for 10 years or so.

moe 12y ago

Why not a library that speaks a simple[1] line based protocol over pipes and/or sockets? Or even just plain old files? That's how unix used to work before the desktop people took over. [1] Yes, DBus is "sort of" line based. But from all I've heard it's the opposite of simple and... well, let's just say people don't seem to have much good to say about it.

swhipple 12y ago
It's true that DBus is somewhat of a complex solution if you have a simple enough use case, and I think most of the criticism is the documentation rather than the design (or, rather, criticism of the design is mostly that it isn't Unix-like). But having a daemon that relays your messages to other applications based on a standardized protocol has some merit of its own, even if it isn't strictly Unix-like. I might have some bias, since I think the Unix-way is oversimplified for some problems, even though there are often ways to make it work.
- moe 12y ago
  But having a daemon that relays your messages I agree, and I'm not opposed to the idea of a daemon. DBus just seems to be (from my perception) rather poorly designed on every level. And the more pervasive it becomes the more of its bad design bleeds into more or less unrelated other software packages. the Unix-way is oversimplified for some problems The unix-way of course has limits, but it's usually worth to explore it as far as possible and only then divert to more baroque designs. In the majority of cases you'll find that pure, file-based approaches are a lot more elegant, efficient, discoverable and debuggable than the alternatives (see e.g. qmail vs postfix, or runit). There's a lot to be said for being able to use the standard unix cutlery to inspect and interact with the guts of your application. Imagine DBus was just a directory with one or two files per pid. Imagine you could read past messages with 'cat', follow them with 'tail' and inject new ones with 'echo'.

deong 12y ago

The kernel has had inotify for 10 years or so.