Hacker News Reader

Comment by general_failure | Hacker News Reader

In this day, I would just use http and websockets instead of dbus even for local communication. It just makes sense

Switching dbus to websocket/http instead of its own outer layer equivalent would get you about 1% done implementing dbus. It doesn't address or answer 99% of why dbus exists or what it does.

So it's a fine thing to consider (since websocket exists now) but I'd question the word "just" here.

It's like saying the way you'd implement an Amazon web service would be to "just use http." OK. Now what is the service? ;-) I hope that makes sense.

It's a mistake to view the problem solved here as "sending messages." The problem is all about the semantics of sending them and the lifecycle services provided by the central daemon.

Can you tell me something which dbus solves but something over http cannot? By this I mean in practice and not what it can possibly do. I have used it KDE and network manager and the like. They are all better off with rest style APIs actually.

That question is like asking "can you tell me something the Twitter API solves that http does not?" - it doesn't make any sense. They are distinct layers. One builds on the other.

http+websocket is a way to set up a full-duplex stream of messages where messages are anything you like.

dbus does have that part, but then it defines additionally what the messages actually look like in enough detail to bind them to method calls; it defines semantics such as guaranteed ordering and errors; it defines a central bus daemon; it adds broadcast messages over the daemon; it adds security features to allow mixing user and system domains; it adds a way to locate the bus daemon; it adds a way to launch and track the lifecycle of named processes; etc, a number of other APIs. It is not just a socket.

Could you implement a dbus-equivalent using http? Sure. But http does not include a "free" implementation of dbus, any more than it includes an implementation of Twitter.

dbus-on-http would have to define how method signatures and types map into http, and then it would still have to actually implement the daemon with its features and semantics.

http wouldn't make any material difference here; it would have some bikeshed-level pros and cons, but not change the system design in a material way.

I get all that. What I was trying to say is that services that provide REST api's are better and easier to use than those that provide DBus api's.

How are REST and DBUS exclusive alternatives? DBUS is a protocol, REST is a protocol-agnostic architectural style. Why not use the REST architectural style when defining DBUS APIs?

Or is "REST" being used to mean "HTTP" here?

It's probably straightforward to write an HTTP server which exposes everything on the bus as an http API, if someone wants a free project idea.

Reply on news.ycombinator.com