Re: telepathy

[Zajcev Evgeny <lg.zevlg@gmail.com>]

Michael Albinus <michael.albinus@gmx.de> writes:

> Zajcev Evgeny <lg.zevlg@gmail.com> writes:
>
>> We are also working on some complex, but interesting bindings to
>> libtelepathy in order to create tool for multiprotocol IM and
>> collaborative editing in SXEmacs.  This is pretty time consuming task
>> and we surely need a help, if GNU Emacs community will have same FFI
>> API then we could unite our efforts to enhance Emacsen..
>
> Some months ago I've started with telepathy.el, using Telepathy's D-Bus
> API. This work is currently stalled due to lack of time :-(
>
> Wouldn't it be an approach to join our efforts?

sure, I'll describe my story:

Some time ago, I've implemented partial FFI bindings to:

 - libempathy
 - libglib2
 - libgobject2
 - libdbus-glib
 - libgtk-x11
 - libmissioncontrol-client

it was enough bindings to implement skeleton for IM.  It was able to
connect, send, receive messages from any IM protocol supported by
empathy, fetch avatars, private info etc - pretty limited, but enough
functionality IM skeleton.  I've been even using it for couple of
monthes as my primary gtalk client.  But empathy got evolved, their
API was extremely unstable, finally they decided to get rid of
libempathy in favor to libtelepathy.  Now they are in active position
in deciding what to put and what to remove from libtelepathy, they are
waiting for recommendations from developers about its (libtelepathy)
functionality.  I'm now collecting some kind of 'recommendations list'
for empathy community to make their codebase reusable and more
friendly for other developers.  My most intentions is to have two
kinds of API in libtelepathy:

 - Low level D-Bus stuff, that they already have
 - Stable high level API that would resemble former libempathy

Having such diversion will allow developers (other then empathy
community) to easily implement IMs, and to lower the level at any time
they need a details.

As to Emacs, I'm very sure that model when emacs does use external
programs and wraps them into lisp level functionality is great!, but
in some circumstances that is not enough flexible, sometimes you need
direct access to API.  Each time implementing C-to-lisp wrappers for
different APIs is not that great as having solid FFI implementation,
when you can write such wrappers entirely in lisp.  So Emacsen C code
for D-Bus, ImageMagick, etc is inferior to 100% pure lisp (without
performance impact!) implementation in SXEmacs using FFI.

thanks

-- 
lg