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. _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
