[Ipcf] Telepathy Specification v0.11

Robert McQueen robert.mcqueen at collabora.co.uk
Thu Dec 1 15:35:28 EET 2005


I've just tagged ("specification 0.11") and uploaded a new version of
the specification to address the TODO items which arose since 0.10. This
should be the last batch of compatibility breaks unless something major
shows up. Changes listed below. As ever, the spec is available at:
 http://telepathy.freedesktop.org/spec.html

Unfortunately this means that the prototype in the mainline of the
telepathy-python tree is now broken, because I've not had time to fix it
for these spec changes. Patches to fix the prototype against the new
spec would be greatly appreciated!

If you want to try the last working prototype version from our
repository, use something like:
 darcs get --tag="0.2" \
 http://projects.collabora.co.uk/darcs/telepathy/telepathy-python

The D-Bus patches we've done are now all integrated upstream in their
new 0.60 release. Hurrah. :)

Regards,
Rob

Changes since v0.10:

* Remove the authentication-realm, authentication-username and
authentication-type arguments to Connect(). These were added for SIP but
aren't really useful - the realm is provided by the server when it
challenges us for authentication, and we then have to reply with a
username and password which is is happy with. If this username and
password isn't the one the user already gave us in username/password, we
need to add a connection interface for challenge/response authentication
so we can ask the user.

* Change the methods which deal with handles to take and return the
handle type as well as the handle number. This essentially splits up the
handle numbers into three number spaces, and clears up really odd
behaviour where you could try and add a room handle as a member of
another room, etc. Anywhere where it's valid to take more than one type
of handle (such as RequestChannel) now has a handle type, most other
places will only take one type of handle.

* Added a CONNECTION_HANDLE_TYPE_NONE for when you are providing no
handle to a method that takes a handle type and number.

* To Connection.Interface.Aliasing, added a flags to indicate whether
aliases on the server can be set by the user, rather than the remote
contact. Changed the SetAliases method to take a contact handle for
using this. Necessary because Jabber roster entries have nicknames that
you set, not the contact.

* Change poorly-defined idle times in the Conn.Interface.Presence to be
"last active" timestamps, to make calculations and timers easier.

* Removed the Channel.Interface.Named in favour of making GetHandle
valid on every channel. This will return the same handle that you
provided when requesting the channel, is emitted in the NewChannel
signal, and is the same handle that's shown when you ListChannels. This
is far more consistent: a conversation with one person has that person's
handle, a chat room has a chat room's handle, a list on the server has a
list's handle, and everything else which is defined in some other way
(like an anonymous grouping) will provide its information via another
mechanism (group interface).

* Move GetMembers and GetSelfHandle into the Channel.Interface.Group
because it makes no sense to try and let a client pretend the member
list doesn't change if it doesn't support this interface. The result
would've allowed idiocy like: request a direct channel with Bob,
actually be given a group channel where Bob is a pending member, and
refuses the request, the user is never aware that Bob is not actually in
the channel.

* Add flags to the Channel.Interface.Group to show when a message can be
provided to the server, eg when inviting someone, removing them, etc.
Add a message argument to the AddMembers and RemoveMembers calls so this
message can be provided.

* Added a Channel.Interface.Hold to allow specifying whether or not a
user in a media channel should stop sending you media, and to alert the
UI if a remote user has put you on hold.



More information about the Ipcf mailing list