[Telepathy] Status of Telepathy Python

[Danielle Madeley]

On Mon, 2011-06-06 at 21:26 -0400, Mystilleef wrote:

> I don't understand why though. I thought Telepathy was just
> a DBus API. So maintaining the Python bindings against the
> the DBus API doesn't sound too complicated. Afterall, all
> we're doing is just calling DBus APIs in Python. I'm I
> missing something?

We actually want to move people away from direct use of the D-Bus API
and towards using high-level, easier, useful API that calls the D-Bus
API for you.

> > The future of writing Telepathy in Python is likely tp-glib via
> > gobject-introspection/PyGI. This is how gnome-shell does it's Telepathy
> > integration in Javascript. I don't know that anyone has tried writing a
> > Python client in it today, but someone has to go first.
> 
> I don't mind going first if I'm nudged in the right
> direction. Are there any example code? Can I write a full
> blown SIP client using tp-glib via PYGI today? Are there
> any limitations?

There isn't example code doing this in Python yet. You'd need to use a
combination of the javascript code in gnome-shell, the telepathy-glib
examples + any notes that exist on how PyGI generates API. People on
#telepathy (irc.freenode.net) would gladly give you assistance here;
it's our goal that this works, but no one has any time to work on it at
the moment.

There may be limitations, bugs that need fixing. Again, we haven't ever
actually tested this, besides some very initial work I did a long time
ago.

You may end up having to make fixes to the introspection annotation in
tp-glib, and find that pieces of high-level API you need are missing.
OTOH, you _should_ be able to write a client at least as complete as
gnome-shell.

> I agree explaining architecture is very important. It's what
> drew me to telepathy. However, architecture does no good
> when you can't figure out how to use the API. Just the same
> way theoretical knowledge is no good without practical
> experience. Case in point, the new architecture recommends
> you use Account Manager/Accounts and Channel Dispatchers to
> manage connections. However, All the example code I read
> seem to be using connection managers directly to do this.
> The docs don't show "how" to do this either. So there's very
> good explanation, but at this point the explanation is
> not useful if I don't know how to put it into practice. I
> know I'd eventually figure it out if I play long enough with
> it or read some source code, but I think the experience
> could be improved. When it comes to documentation "how",
> "why" and "when" is a lot more important than "what".

Yeah, I know about the lack of up to date examples, and I apologise for
this. Most of the example code written for the docs predates Mission
Control 5. The docs themselves are in this hacked up state where they
include some discussion about the modern state of affairs, but it's a
bit mismash and there are not enough up to date examples.

> I don't want to be completely negative. So I'll add I was
> able to figure out some stuff using the DBus Spec and the
> developer's handbook which does a fantastic job explaining
> the architecture of Telepathy and would be even better
> if the current examples (the Python ones in particular) are
> updated and perhaps even more added.

I happily welcome contributed/updated examples. Unfortunately I don't
have any time to really invest in the docs at the moment.

> >> https://bugs.freedesktop.org/show_bug.cgi?id=35314
> >
> > This bug is a mistake in how someone is using the API, not a mistake in
> > tp-python.
>
> What is the right way to use that API?

Telepathy is meant to be used entirely asynchronously. You need to ready
the object. Pass the keyword-arg ready_handler with the name of a
callback for when the object is ready. [Notice also here the
asynchronous method call.]

For instance:
        
        def main():
            account = telepathy.client.Account(
                '/org/freedesktop/Telepathy/Account/' + sys.argv[1],
                ready_handler=_account_ready,
                error_handler=_error)
        
            loop = gobject.MainLoop()
            loop.run()
        
        def _account_ready(account):
            # get the connection
            account[dbus.PROPERTIES_IFACE].Get(ACCOUNT, 'Connection',
                reply_handler=lambda x: _got_connection_path(account,
        x),
                error_handler=_error)

In the tp-glib API this is called "preparing" an object. It does things
like requesting the core properties, such as what interfaces are
available on the object.

> After establishing a connection I can't use the
> CONNECTION_INTERFACE_REQUESTS DBus interface at all.
> 
> connection[CONNECTION_INTERFACE_REQUESTS] always raises an
> error. I'm I not supposed to call that interface?

Well, ideally you should make your requests to the ChannelDispatcher,
which will forward them to the appropriate Connection for you. However
your problem is not having prepared the object, so it doesn't know what
interfaces are available.

> >> QT does a fantastic job with their documentation it can be a
> >> source of inspiration for the Telepathy framework.
> >
> > Have you considered Telepathy-Qt4?
>
> 5 years ago, I would have jumped at Telepathy-glib or
> Telepathy-QT4. However, my days of writing desktop clients
> in such languages (C/C++) is over. This is why I'm surprised
> the Python bindings for Telepathy gets the least love. GIT
> tells me the Python telepathy module has not seen any
> commits in 5 months. I'm finding it hard to believe
> developers today would choose Glib and Qt4 bindings over
> Python. I'm I missing something? The situation seems to be
> the reverse in most frameworks I've used.

The interest in Telepathy on embedded devices means that languages like
Python are not getting a lot of focus [additionally I have opinions on
the appropriateness of languages like Python for big apps]. Furthermore
we realised that maintaining n bindings for n languages was not a
scalable use of our time, especially if we had to write a high-level
binding in each language separately. Hence we began work on
gobject-introspection for telepathy-glib and eventual deprecation of the
low-level bindings.

The future now is to support Python and Javascript via tp-glib +
gobject-introspection (almost all CMs require tp-glib anyway).
telepathy-python will probably continue to exist to provide service-side
bindings for tp-butterfly and tp-sunshine [it would be neat to provide
g-i bindings for tp-glib's service-side, and completely remove
tp-python, but that's a long way off].

--danni

-- 
Danielle Madeley
Software Developer, Collabora Ltd.                  Melbourne, Australia

www.collabora.co.uk