[Telepathy] Writing and using a Gabble extension

[Guillaume Desmottes]

Hi all,

These last days I spent some time writing a Gabble extension as a plugin
and making use of it in an external application.
I'll present the extension itself once it's ready but for now I'd like
to share my experience. I think we've made good progress improving our
API and infrastructure to allow 3rd party developers to extend and
integrate Telepathy into their apps but there are still plenty of room
for improvements. To be honest, it's still far from being as easy as it
should be and I wouldn't be surprise that's enough to discourage lot of
people.

 
Service side
------------

* Sidecars are great to easily extend Gabble but they really lake
documentation. Some docs explaining the general design of sidecars and
how to start your own plugin would be good. (Thanks to Will for his help
btw).

* As I'm pretty use to Gabble's code it hasn't been too hard for me to
get started by cargo culting the gateway plugin. Maybe we could have a
script in tools/ generating all skeletons for a new plugin (plugin's
dir, its source file, a test using it, etc). epiphany-extension has
something like that and it's very convenient.

* Oth we could argue that plugins should be developed into their own
source tree rather than in Gabble. I didn't test this approach but I
suspect it's far from being trivial (especially if we want to be able to
write Python tests). Having a gabble-plugin-skeleton directory
containing all the boiler plate for the plugin, the extensions black
magic to generate interface and the tests infrastructure would be really
useful.

* Implementing the plugin isn't too hard assuming you are familiar with
Wocky (which I am as I wrote some parts of it) but some doc explaining
the general design of Wocky components would be useful for newcomers.

* My plugin uses PEP and the WockyPepService is very handy but this bug
makes it unusable without patching  src/capabilities.c to subscribe to
notifications:
https://bugs.freedesktop.org/show_bug.cgi?id=24134
Unfortunately it's not easily fixable without moving all the
capabilities logic from Gabble to Wocky.
Maybe as a short term solution Gabble could offer API to plugins?


client side
-----------

* Generating client side API is really a pain. We have to copy the tools
and directory extensions from another project and badger the build
system until it works as expected. We should really try to improve that,
it's the most annoying issue I faced.

* Watching for connections requiers much more code than it should do.
Once again I reused my ConnectionWatcher object (initially written for
Azimuth). I still think that allowing Observer to observe connections
would be an easy solution for this as I suggested in
https://bugs.freedesktop.org/show_bug.cgi?id=28974

* Once the sidecar API has been undrafted it would be nice to have a
TpSidecar object in tp-glib sub-classing TpProxy. We should also have a
high level API to request such object.

* Getting the contact list is still a pain (I cheated and only request
the 'stored' list as my plugin only work with Gabble anyway) but
hopefully this should be fixed soon with the new ContactList API \o/

* Speaking of ContactList, it could be handy for extensions to be able
to define their own Contacts attributes so clients would be able to
fetch the plugin-specific data using RequestContactList().
If we'd add hooks in TpContact to store these data to the TpContact
while parsing the Contacts attributes, it could be pretty convenient for
the client to get all the contacts + their data in just one function
call.
I explained this crazy idea in
https://bugs.freedesktop.org/show_bug.cgi?id=24661#c11


That's all for now :)


	G.