Merge lp://qastaging/~mhr3/dee/shared-private-connections into lp://qastaging/dee

I need to understand this correctly. Given this branch DeeServer will
always just create one socket as long as you use it with
dee_server_new(swarm_name) for varying swarm_names. The swarms will be
multiplxed by the DeeServer instances.

The new sockets will be created if you create DeeServers with non
standard addresses.

Correct?

Not exactly, dee_server_new will keep current behaviour (separate socket for each different swarm_name). But you'll be able to do dee_server_new_for_address with varying swarm names, but the same bus_address.

The reason for this is that we need a well defined socket name for the server, so that dee_client_new can work properly.
Or to try to explain better, consider that dee_server_new would try to always use the same bus_address - this would mean that if there were two completely unrelated processes which are trying to use dee's private connections (both servers). They would try to create the same socket, so one would necessarily fail. Moreover we can't just add a pid to the socket name, otherwise DeeClient in a different process couldn't easily connect to the server.

I hope that makes it clear-ish. :)

The problem this brings though, is that DeeServers will be emitting peer-found & lost for peers from different swarms, which is sort of odd, but I don't think too much of an issue.

(the idea also is to use the same GDBusConnection for clients using the same bus_address, but that doesn't really create any problems unlike the server-side)

Can you add a detailed explanation of the behavior to dee_server_new() and dee_server_new_for_address()? It's crucial knowledge for consumers to know if/when they create sockets - and it'll help the review a lot.

Doubly important to know precisely when sockets are created if we ever switch to something that supports socket activation (like systemd fx.).

So to be clear, the socket creation semantics becomes a part of the public API.

On it...