[Telepathy] Connection.Interface.Requests Spec Question

[Edward Page]

Thanks for the reply.

> You might gain some insight by reading
> http://people.collabora.co.uk/~danni/telepathy-book/sect.channel.requesting.html

Unfortunately neither the spec nor that document address whether
RequestHandles is to be called explicitly by the client prior to
calling CreateChannel/EnsureChannel.

> Basically, properties in the requests interface can be any D-Bus
> property accepted by an interface, e.g.
> org.freedesktop.Telepathy.Channel.TargetID.

> Older clients will still work with CMs supporting the Requests
> interface. The mixins are provided to make it possible to support both
> interfaces from a single codepath. Also to handle things like automatic
> conversion of TargetID to TargetHandle, etc.

More specifically in the code.  Older clients would call
RequestHandles for the TargetID (which is the handle name and not to
be confused with the handle id) which would return the TargetHandle.
Then the client would call RequestChannels to get the channel for it.

python-telepathy's implemenation of CreateChannel/EnsureChannel calls
_alter_properties before the call to channel_for_props.  If the
TargetHandle is not specified, this function loops over all the values
in the connection's _handles looking for one of the same TargetID
trying to find it.  It will raise an exception if the TargetID is not
found.  This seems contradictory, if the handle has to already exist
then the client should have the TargetHandle then why call with the
TargetID?

When experimenting using dbus-monitor and logging within my CM on
Maemo 5, I saw no calls to RequestHandles prior to the call to
CreateChannel/EnsureChannel.  This gives me the impression that it
expects the CM to do the equivalent of RequestHandles inside of
CreateChannel/EnsureChannel which the Requests mixin does not do.

This code path within the Requests mixin seems suspect anyways.  It
assumes the handle is the same if "handke.get_name() == TargetID".
This raised a red flag for me because I do some normalization on the
name in the call to RequestHandles so even if the handle existed, this
comparison would always fail.  I looked into telepathy-butterfly and
it almost does similar.  it removes the extension in RequestHandles
but re-adds it within ButterflyContactHandle.__ini__.  If
CreateChannel/EnsureChannel within the Requests mixin called
RequestHandles or an equivelant, then both issues are gone for me.

> Have a look how things are implemented in telepathy-butterfly.

I've been very grateful for telepathy-butterfly, I've heavily based my
code off of its design and have used it to figure out how to adjust
things between releases.

Ed Page