4 ms·
>TI-RPC/SunRPC plays a big role here. It's much leaner than D-Bus and at least nominally capable of network transparency Isn't that true of D-Bus as well? I me
by catern 11y ago
>TI-RPC/SunRPC plays a big role here. It's much leaner than D-Bus and at least nominally capable of network transparency
Isn't that true of D-Bus as well? I mean, maybe it's just semantics, but if you're going to use the word "nominally" (read as "it claims to be") when saying it's network transparent, D-Bus is certainly "nominally" network-transparent as that's an advertised feature of it.
- vezzy-fnord 11y agoNetwork transparency is most certainly not an advertised feature of D-Bus. There has been some experimentation, but nothing concrete has ever come out of it. Nor does anyone really use it as a remote protocol. In contrast, SunRPC is RPC, so network transparency is a given. The reason I said "nominally" is because in the case of SystemXVI, having proper distributed service management (not a goal at this point) would require more than that.
- catern 11y agohttp://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html Search for "TCP".
- wnoise 11y agoNote the complete lack of security. (A shared secret sent in plain text is not security).
- EmanueleAina 11y agoI guess it's meant to go over TLS, just like HTTP basic auth.
- EmanueleAina 11y ago> having proper distributed service management Which is more or less what CoreOS's `fleet` already does on top of systemd. They used a different protocol for remote communications (etcd, ie. HTTP+JSON) vs. local, which I guess can be a sensible choice as requirements are quite different.
- vezzy-fnord 11y agoYes, and they had to create an ad-hoc layer over systemd using a particular K-V store. Contrast to the more generic and seamless option of RPC interfaces, which are more versatile in making policy decisions.