Isaac Dunham <ibid.ag@???> writes:
> On Sat, Nov 14, 2015 at 07:36:08PM +0000, Rainer Weikusat wrote:

[...]

>> OO RPC system intended to enable long-running
>> applications to call methods implemented by other long-running
>> applications provided these other long-running applications run on the
>> same computer.
> <snip>
>
> Your explanation is pretty good.
> But there are a very few more details that I thought should be mentioned:
>
> - Regarding 'long-running', it seems worthwhile to mention that D-Bus
> is the main *stateful* IPC protocol available.
> In other words, it is designed around the concept that you're dealing with
> programs that will not be restarted.
> This, apparently, makes it simpler to use, since rather than dealing with
> failures of the 'remote' process, you can simply ignore them because it's
> irrecoverable anyhow.

s/irrecoverable anyhow/just a problem for users, so fuck it/

[...]

> - Regarding 'on the same computer', it's apparently supposed to be
> 'possible' to set up some method of forwarding over ssh.
> I saw references to this being already implemented in one of the threads
> Miroslav posted in; but as far as documentation goes, I see only a
> two and a half year old page mentioning it as a possible but untested
> solution.

It's obviously possible to relay between AF_UNIX and AF_INET stream
sockets, eg, I have a C program here (944 LOC) dedicated to doing just
(and do it fast) I wrote in order to connect two computers to the same
instance (and thus, URL database) of a web content classification
program but this really only works when the server is stateless because
the relaying program can then transparently reconnect to it. It also
doesn't turn a protocol designed to work by block memory copies into one
which will work sensibly/ efficiently over TCP, especially when latency
start to become measurable (eg, the RTT between Europe and the USA is ca
0.1s), segments are getting lost or there's only little effective
bandwidth available. And then, of course (I take your word for that), the
fantasy that programs are started on boot and keep running until the
heat death of the universe becomes absoluty untenable once more than
one computer is involved. And then, of course, simple forwarders provide
neither authentication nor integrity protection nor content
confidentiality. It's possible to work around that by using a real VPN
($person has a clue) or tunneling over ssh ($person is on a "baffle them
with bullshit" mission) but that's the point where the "workaround"
starts to become more complicated to maintain than the facility itself.

Lastly "everybody's darling is nobody's friend" (I'm afraid but I have
to quote myself here): A protocol which is design to be usable in any
conceivable situation will be an awkward choice for most actual
situations. I implemented a system for forwarding SNMP (v2 of course)
securely over the internet and query/ control printers speaking SNMP
over USB in the past. A D-BUS<->ASN.1 bridge would neatly fit into this
and take the pleasing impenetrability of the system to a whole new
level.