Question regarding the Telepathy prpl

[Will Thompson]

sttwister at gmail.com wrote:
> 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.

I think this is the right approach. I suspect that with some cleverness
you could do roughly what you described, but it would make sense to
improve the prpl-loading API to do this cleanly in the long term.

Just exposing a generic "Telepathy" protocol will probably be a faster
path to getting something working; but then again an even faster path
would be just to hard-code which protocol the Telepathy prpl exposes and
come back to this later.

> 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.

I think this is somewhat orthogonal to the other issue. If the Telepathy
code were still a prpl, you'd still need to do either i or ii above in
order to pass the relevant stuff down it. I think the best approach here
would be to add API to hide a prpl, and have the Telepathy prpl hide
native protocols that it also exposes. But this is "later" material. :)

-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090422/0f0fa89c/attachment.sig>