(Written on Friday 16th, posted on Monday)

As I write this, I'm on a plane off the coast of the Netherlands, on the way back from a couple of days designing APIs with Rob McQueen and the RTCom people at NRC Helsinki (who we work with on the chat and VoIP functionality for Nokia internet tablets).

We've had a very useful couple of days, mainly designing the next-generation channel requesting and dispatch API for Telepathy (the same APIs I've been doing preparatory work for on the Telepathy mailing list in the last couple of weeks). API sketches for review and comment are either on are on Merge Monkey or on the way there.

Before even reaching Nokia, Rob and I did a lot of design on the plane over to Helsinki, and I took some notes: here they are, by way of a glimpse at how the Telepathy design process works when we don't have a whiteboard1 :-)

  • Geoloc looks good in principle, needs some more work

    • add more docstrings

    • add a way to ask people for uncached info (RequestLocations)

    • move access control to Co.I.Presence, call it RichPresenceAccessControl?

  • DeliveryReporting looks good, ish

    • improve wording of delivery-echo and rationale

    • when sending a delivery report, add a reason for the status (using Channel_Text_Send_Error?)

  • Uniqueness requirement for (channel, handle_type != 0, handle) is in the way - let's drop it

  • MSN should use "authentic" 1-1 chats, and use Ch.I.UpgradeableToRoom (name tbd) to migrate the underlying switchboard to be a room

  • XMPP should use Ch.I.UpgradeableToRoom too, but the 1-1 channel may also stay open

  • Mutable handle => handle 0 must stay (for requestotron's benefit)

  • bundles ftw

  • renaming: we want SelfHandleChanged in the core

  • TpC* - add ability to subscribe to ifaces at construct time (blocks Ready) or later

  • Dispatching: when registering a c'handler, specify everything it can handle

  • If a new bundle can be handled in its entirety by the same handler (call it 'the bundle handler'), do it. Otherwise split it up completely (there is no 'bundle handler').

  • If a channel in an existing bundle can be handled by the bundle handler, send it there, else send to the default handler.

  • Group - add SelfHandleChanged, maybe? Also Connection

  • Add HandleOwners: prop a{uu}, HandleOwnersChanged(a{uu}, au)

  • Use TargetHandleType, TargetHandle

  • Stringified initiator handle as a separate property

  • Maybe even a FirstMessage property, although this stretches the definition of "immutable"

  • org.freedesktop.Telepathy.Client interface

Mikhail Zabaluev kindly took notes for some further discussion we had with him and Alberto Mardegan about the dispatch API, which he already posted to the mailing list.

We hope this API will make it possible to integrate Telepathy into the desktop better - it should make it a lot easier to share connections between processes in a useful way and hand out incoming channels to the appropriate handlers, which was always a major goal for Telepathy. It should also let us and others implement exciting new notification mechanisms (hi to the people on IRC and the mailing list wanting to patch their media players to integrate with Telepathy! :-)

  1. When we do have a whiteboard, the design process is: "Robot101 scribbles on a whiteboard, smcv writes down <tp:rationale> elements"