Probably not very big of a problem, which is why we're merging STS although it has this limitation. The API has sufficient flexibility, though, to allow adding Unix socket support later. Reasons it was left out originally: - TCP sockets allow us to more conveniently associate ongoing connections with the remote contacts they're from as long as the CM supports Socket_Access_Control_Port (gabble does), as there are only so many (256) different 8-bit credential byte values for Unix, and credential bytes can't be even used with all protocols as they are in-line with the protocol bytestream - I don't know of any services which couldn't be configured to also listen on TCP. X11 and cups can be, for example - so they're likely to be exported as TCP services due to the above limitation with connection monitoring - The spec only requires CMs to support TCPv4 sockets too. Gabble supports all the address types anyway though. Reasons why it would still be nice to have one day: - Maybe better performance than TCP sockets for the same service? Dunno how much better, or if at all on practical systems. - Credentials AC allows restricting the processes allowed to connect to those from the same UID (like our protocol backend), without explicitly authenticating using the tube payload protocol - After all, some services might be really Unix only. At least X11 is in its usual distro configs (-nolisten tcp) and it's a bit crappy to have to change that.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-qt/issues/25.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.