[Bug 35084] tp-qt4: Design and implement API for easily being a StreamTube Handler

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=35084

--- Comment #1 from Olli Salli <ollisal at gmail.com> 2011-04-25 13:33:09 PDT ---
An initial draft of the Offerer side API is at 

http://cgit.collabora.co.uk/git/user/oggis/telepathy-qt4.git/tree/TelepathyQt4/stream-tube-server.h?h=streamtube-handler&id=2cc2d465ce2b0d48f6bf6ab1ba07a4b1346db76d

Comments welcome.

The basic idea is that minimally, you only have to create the StreamTubeServer
and call exportTcpSocket with your listen socket, and you'll get all outgoing
tubes handled by that socket being Offered on the tube. A QTcpServer overload
is provided for convenience, but it's only meant to extract the current listen
address of the server, not establish any kind of linkup.

For richer Telepathy integration monitorConnections = true can be passed to the
create() method. This allows associating particular connections to the listen
socket with the Telepathy contact who connected to your exported service
through a tube, and getting informed about the Telepathy-level connection
errors (so you can get more than just a close event / read error on your
socket). I imagine these would be useful for especially GUI applications, which
might then e.g. show the face of whoever connected, but also for logging
Telepathy metadata for connections in server daemons.

I had the UNIX socket support API drafted as well but I felt the TCP/UDP
duplication took attention away from the overall concepts of the API. Perhaps
it should be a separate class, if we need it at all? Are people in practice
likely even want to export UNIX socket services? X11 and CUPS come to mind as
potential uses, but both can be configured to also listen for localhost TCP
connections.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.