[Telepathy] telepathy-python bug fixes?

[Olivier Le Thanh Duong]

Hi,
On Fri, Jan 15, 2010 at 3:18 AM, Edward Page <eopage at byu.net> wrote:
> On the page for telepathy-python I did not see any procedure for
> reporting bugs or who to go to for pull requests.
> http://telepathy.freedesktop.org/wiki/Telepathy%20Python
>
Sorry this page is totally outdated, I will correct it.
The place to report telepathy-python bugs is in the freedesktop
bugzilla, product Telepathy in component tp-python :
https://bugs.freedesktop.org/enter_bug.cgi?product=Telepathy&component=tp-python

> I'd like to thank Danielle for helping me determine what the expected
> outcome was.
>
> Version: 0.15.13-1
>
> Reproduction Steps:
>
> 1. In a telepathy client (tested in RTComm) the user selects "Send IM To"
> 2. The user enters the contact identifier for someone not on the
> contact list (so no previous handles created)
>
> Expected Outcome:
>
> 1. Clients will call ConnectionInterfaceRequests.CreateChannels with
> TargetHandleId set as the contact name.
> 2. CreateChannels (through _alter_properties) calls an internal
> equivalent of RequestHandles to get a TargetHandle for the
> TargetHandleId, creating a new handle if needed.
>
> Actual Outcome:
>
> 1. Clients will call ConnectionInterfaceRequests.CreateChannels with
> TargetHandleId set as the contact name.
> 2. CreateChannels (through _alter_properties) searches among existing
> handles, checking if the "get_name() == TargetHandleId"
> 3. The handle has not previously been created and an exception is raised
>
> Notes:
>
> This puts on the requirement that the handle had to already exist
> which makes calling without a TargetHandle pointless.
> Handle.get_name() is checked directly against user input, not allowing
> CM implementers to normalize the names that come in
> When constructing the exception that gets thrown for an invalid
> contact, the string formatting is setup incorrectly and a different
> exception will be thrown instead.
>
> Fix:
>
> I've branched the latest Master of telepathy-python.  I extracted code
> from the default implementation of RequestHandles and made it a
> function called "get_handle_by_name".  I then made the requests
> interface call that.   As a parallel function, I also implemented
> "get_handle_by_id" which is a simplistic function that clients are
> expected to implement for the Channel mixins (previously the channel
> mixins called it "handle" which I found quite an ambiguous name).
> git://github.com/epage/telepathy-python.git
>
I didn't review your patch yet, but you are right about the expected
behaviour, tp-python shouldn't require you to create the Handle before
calling request channel. I guess we didn't notice before because the
use case wasn't present in Butterfly.

Previously the naming was ambiguous but it has been stated clearly in
the spec now that the Handle would refer to the numerical value while
the Identifier would be the string corresponding to it (the other
problem being  that in tp-pyton/butterfly, Handles actually are class
instances)

> In my CM, I removed my implementation of RequestHandles and took my
> special logic and put it in my own implementation of
> get_handle_by_name.  Also to have direct access to fixes like this,
> I've included all the files from telepathy-python/src/server/*.py to
> be distributed with my code.
> https://git.maemo.org/projects/theonering/?p=theonering;a=summary
>
You should never have to copy the bindings in your own repository,
instead use proper subclassifications.

> Ed Page
Regards,
 Olivier
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>



-- 
Olivier Lê Thanh Duong <olivier at lethanh.be>

Phone : +32485608639 Jabber: olethanh at gmail.com