Jason's hands were tired after typing two days of excellent notes on sessions at the Gnome Summit, so I took over writing up the Telepathy BOF (which was largely about Telepathy integration in Gnome Games).
Gnome Games's tubes code is broken because of Empathy moving to Mission Control 5, which broke the contact chooser they were using (which used Mission Control 4). A Canonical person (your scribe did not catch who it was) has written a contact selector in C which just uses telepathy-glib, which Gnome Games will use and then start working again. This widget could form the basis of the long-anticipated telepathy-gtk.
Rob pointed out that it's currently a bit of pain to request a channel for yourself: you can't just call one D-Bus method and get a channel back, you also have to implement a Client.Handler object on which MC will call the HandleChannels() method. Sjoerd noted that Empathy has helper code for doing this in simple cases, which could be moved to tp-glib (it's under the LGPL).
Jason wants a way to share high scores with your contacts. (Digression about a gnome-games high score server on gnome.org ensued, the notes of which your scribe lost in a kernel panic. One main point is that global high scores end up just featuring incredibly good scores and people setting their name to obscenities.) Jason wonders if g-g could publish your high scores to your contacts in the background?
- Rob and Will suggested that in principle this could use PEP on XMPP, which allows you to publish a blob of information to your XMPP server and be notified when your contacts' blobs change. (This is how Geolocation works in Empathy, for instance.) Unfortunately Google's server doesn't support PEP, so most people wouldn't be able to use this; plus, it would need an extension in Gabble.
- Another way to do it would be to initiate file transfers behind the scenes.
- Rob suggested using tubes. Gnome Games would come with a tiny daemon that handles tubes for the "org.gnome.games.highscores" service, serving up your high scores to anyone who asks. Then, when you open a high scores table, it would use ContactCapabilities to discover which of your online contacts support that service, and then ask them for their latest high scores (with a cache and a rate limit, obviously). It could show a throbber while it's doing this. Jason thinks this sounds like a good idea. Prerequisites: you need the latest MC and Gabble 0.9 in order for ContactCapabilities to work, but that's it.
J5 wondered if any g-g people are documenting how they're using tubes, because he was always confused by them, and he reckons this is a very important thing for app developers. Rob suggested pushing this into tp-book, and Sjoerd noted that Danielle has a
helper which lets you say "give me a stream to this person" and get a GIOChannel back . J5 thinks that if patterns for using tubes were really well documented, people would jump on the chance to use them.
Jason mentioned that people were discussing having a help option which jumps you to #gnome-games-$lang. J5 said that Ximian tried that, but found that people would just end up in empty chatrooms or paste goatse at each other. Integration with DevHelp would be nice to let people post examples etc.
J5 suggested that another good way to improve documentation is to make writing it a requirement for SoC. Rob noted that Telepathy hackers know that you need to use, eg., a Handler and a Tube, but it's hard for people really immersed in the stack to remember which prerequisites people need to learn in order to understand that stuff. Sandy said they'd been discussing documenting requirements and standards for SoC students, and thinks it's a great idea to ask students to blog stream-of-consciousness "this is what i did" updates. People have to make sure that they do this as they go along, because you forget the learning process after a few weeks.
Advantage of peer-to-peer high scores: you don't get the problem of one incredibly good person dominating. ajaxxx suggested that you could make high scores decay over time, or once you reach a particular level, to address this problem.
Tetrinet is latency-sensitive: will that be a problem with Telepathy, particularly using MUC tubes? Rob said just try it and if it's too slow it'll get faster as the implementation of Tubes improves. Sjoerd noted that for tetrinet you probably want to just export the Tetrinet server over a multi-user stream tube, rather than using d-tubes.
Telepathy should use UPnP to make FT and tubes fast in more cases. This is on the TODO list.