| Summary: | InterfaceFactory._valid_interfaces is not really valid before connection | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Fabien LOUIS <flouis> |
| Component: | tp-python | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Patch to fix _valid_interfaces attribute | ||
|
Description
Fabien LOUIS
2010-03-04 06:32:44 UTC
This is more of a documentation bug: the valid interfaces aren't necessarily known until the connection connects, so the result of GetInterfaces() is incomplete until CONNECTED is signalled. (Also, telepathy-python shouldn't block on D-Bus calls as your patch does.) The right thing to do is not trust _valid_interfaces to be complete until the Connection signals that it is "ready" (I believe there's a ready_handler __init__ argument or something? Yep there is a ready handler, but it is emit when Connection is CONNECTED (which is good). So if I want to call SetPresence before calling Connect() (so before CONNECTED), I need a right _valid_interfaces attribute. Currently (before my patch), if we cant to change presence before calling Connect(), I get a KeyError because org.freedesktop.Telepathy.Connection.Interface.SimplePresence isn't in _valid_interfaces. I think we need an attribute which is always valid no? The attribute can't always be valid (without blocking the main loop, which is bad - <http://smcv.pseudorandom.co.uk/2008/11/nonblocking/>), since on a newly created Connection we just don't have that information yet - we have to ask over D-Bus, which takes time. I think what you need to pre-load SimplePresence is something that resembles ready_handler, but can run as soon as the initial Status and Interfaces have been fetched, without waiting for CONNECTED. telepathy-qt4 has a mechanism like that, and putting a similar thing into telepathy-glib is among my medium-term plans for Telepathy. I'm not sure exactly how this should be implemented in telepathy-python, which doesn't natively have any mechanism for signals; perhaps binding telepathy-glib into Python would be a better long-term solution for this sort of thing. (In the meantime, if you know through out-of-band information, or your own call to GetInterfaces, that the Connection has the SimplePresence interface, I believe you should be able to just make a dbus.Interface for it, and call the method on that?) Yes I could bypass this by creating a specific code for this case but I don't want to patch my code :) So I prefer use your bindings all time. Anyway, for moment, the current method (patch) is good for my case. I let you decide how to allow this in the future (for example, calling SetPresence on SimplePresence, before connecting the connection without throw an error). -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-python/issues/12. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.