Thanks for your response Danielle. I appreciate it. On Mon, Jun 6, 2011 at 7:17 PM, Danielle Madeley <[email protected]> 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. _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
