Question regarding the Telepathy prpl

[sttwister at gmail.com]

Some of you already know me, I'm this year's GSoC student designated for working on the Telepathy prpl project. Before starting to work on the actual implementation, I have some design questions that I would like you to shed some light on.

The Telepathy framework supports multiple connection managers and protocols that can be queried in real-time. As far as I can tell, a prpl can only export one protocol. In order to solve this problem, I thought of several solutions:

i) Use a generic protocol called Telepathy
        This prpl would export a protocol called Telepathy. Further choosing the exact protocol would be done by using a parameter for the prpl. The problem with this aproach is that all buddies and conversations relayed through Telepathy would appear to be using the same protocol (the generic one exported by the prpl). Also, it might prove difficult to expose protocol-specific options to the user, which are different for each protocol supported by Telepathy.

ii) Export multiple protocols from one prpl
        I'm not sure if this would be possible without changing the core libpurple API. A hackish version I was thinking of is using purple_plugin_load and purple_plugin_register manually in order to export multiple PurplePluginProtocolInfo structs (that means NOT using the PURPLE_INIT_PLUGIN macro as it is now).I'm not sure if this is even possible at all, so someone please tell me how all this stuff works. The advantage of this method is that each protocol will be clearly specified and known by finch/pidgin and it would reduce user confusion. Since each protocol exposed by Telepathy will be exported in a different prpl, parameters will be handled without any problem. Some confusion might arise to unknowing users if they see one protocol exported by both libpurple and Telepathy in the list.

iii) A "Use Telepathy" switch for each supported protocol
        This solution implies checking for each protocol supported by libpurple if there exists a Telepathy equivalent. If so, a "Use Telepathy" switch could be added to the options which would cause the protocol to transparently use Telepathy instead. I'm not sure how this could work, but hey, it's an idea. Also, how would the other protocols be handled? Maybe this could be used in conjunction with one of the first two solutions. Feel free to extend this possible method if you have any ideas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090422/2f4eca57/attachment.sig>