Telepathy Tubes in KDE/Qt: how and why
Hello folks. You probably already read Daniele’s blog post explaining what he will do this summer. Telepathy tubes are a new, very interesting way of sharing information and applications between you and your contacts. At the moment, I’m in the process of granting a Qtish (hence easy and nice) API for accessing Stream tubes and DBus tubes in Telepathy-Qt4. So let me give you some more insights on what tubes are and how you can use them.
Stream tubes allow you, dear developer, to share an arbitrary socket between you and a contact, or a group of contacts. Sounds cool, huh? It actually is. You can share IP (both v4 and v6) sockets or standard Unix sockets. When designing the new API, we especially thought about making it extremely easy to plug a Stream Tube into an existing TCP logic, so that you can benefit from this additional coolness without having to replace your code, and just by adding a few lines.
When offering a tube, in fact, you just have to create the channel (a one-liner function), and offer it. The offer function accepts either a standard address, or an existing QTcpServer or QLocalServer. So you can simply offer your existing server through the tube and then forget about Telepathy as soon as the tube is opened: you will be able to monitor connections from the server itself.
In the receiver end, instead, things are even easier: when you detect a new tube channel, there is an handy acceptTube() function which returns (asynchronously, just like everything in telepathy-qt4) a QIODevice ready to be used. So it’s just as easy as: accept the tube, retrieve the device – read/write from/to it.
DBus tubes are another nice beast: they allow, just like the name says, to share a private DBus connection with your contacts. Even cooler, huh? Again, of course it is. This part of the API is still work in progress, but in the end we’d really like to return a ready to use QDBusConnection on both offering and accepting side. Of course, in this case you wouldn’t export an existing DBus connection, but instead a new one will be created, where each contact will be advertised as a service name, and services and interfaces can be registered arbitrarly.
Wow… how can I use those?
I already completed the Stream tubes implementation, which is pending to be reviewed and merged onto master. I will start with the DBus one soon, albeit it depends on a merge request for Qt by Daniele itself. Without this patch in, no peer-to-peer tubes I really hope the patch will be reviewed soon, also because it is a blocker for Daniele’s GSoC.
Ok, but I’m a user and not a developer. What does all of this mean to me?
Well, you have to know that nowadays almost every application exports a DBus interface, and it is almost completely controllable through it. Not to mention sockets, of course. This means that such a project will open infinite possibilities for sharing not just data, but whole applications, or Plasmoids (Daniele will do exactly those kind of things) in an extremely easy way. So you will be able to play a KGame with your friends while you should work/study, share your widgets, maybe your music collection, or everything you can imagine: and your only requirement will be having an IM account. Sounds exciting, isn’t it?
Stay tuned, because this is just the beginning.