(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! :-)
- When we do have a whiteboard, the design process is: "Robot101 scribbles on a whiteboard, smcv writes down <tp:rationale> elements"↩