[Telepathy] Status of Telepathy Python

[Mystilleef]

Thanks for your response Danielle. I appreciate it.

On Mon, Jun 6, 2011 at 7:17 PM, Danielle Madeley
<danielle.madeley at collabora.co.uk> wrote:
> Telepathy-Python is mostly unmaintained; especially the client-side APIs
> (where let's face it, there aren't many, nothing high-level, and even
> some of the low-level classes are missing).
>

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?

> 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?

> As the author of a lot of the documentation, I know it needs a lot of
> work. It doesn't document today's best practice, it's strangely
> organised with way too much cross-referencing, and doesn't dealt well
> with documenting the different approaches taken by APIs (also it has 0
> Qt4 documentation).
>
> It is my plan (who knows when) to convert the documentation into
> something topic based (i.e. Mallard) which should allow for much easier
> expansion. Including 'cook book' style examples like you're wanting.
>
> I still think explaining the architecture is important. Lots of people
> fail to understand the architecture of Telepathy, and as a result make
> assumptions, and thus mistakes, when writing their clients.
>

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".

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.


> On Mon, 2011-06-06 at 11:44 -0400, Mystilleef wrote:
>
>> Apart from the documentation problems (documentation should
>> emphasize "how" to do things as opposed to explaining
>> architectural designs and contain plenty examples), it
>> seems as if some interfaces available in the documentation
>> don't even work. See this bug for example.
>>
>> 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?

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?

>> 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.

>> Anyway, back to Telepathy Python. Is it still maintained? Is
>> it wise for us to use it to build an SIP client or should I
>> look elsewhere? Also are there any Free Software Python
>> apps that have been written with Telepathy?
>
> If you're simply writing a SIP client, you may be better served simply
> using a SIP library, such as sofiasip, directly. telepathy-rakia does
> not support everything you can do via SIP. You can still use libraries
> like farsight/farstream without Telepathy to connect between GStreamer
> and your media streams.
>

I began looking at other SIP libraries today reluctantly.
I'll look into farsight using without Telepathy too.

> On the other hand, if you want to use the ability of
> communications-as-a-service, and support many protocols, Telepathy is
> the perfect choice.
>

Yes, I wanted to integrate Google Talk capabilities into the
client that's why telepathy seemed like such a fantastic
idea.