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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
