Question regarding the Telepathy prpl

[Mark Doliner]

On Wed, Apr 22, 2009 at 10:49 AM, Will Thompson <will at willthompson.co.uk> wrote:
> 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.

I agree, option ii sounds like the best approach.

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

+1 to Will's suggestion of pushing this back to later.  Something to
keep in mind... if you can manage to keep the plugin id the same for
the native version as for the Telepathy version (e.g. "prpl-yahoo" for
both) then users see the same set of chat logs regardless of which
prpl they're using.

I think it's reasonable to make changes to our plugin architecture to
make this cleaner.  If you add the ability for a single plugin to
register itself twice, it's possible it could be used by the oscar
prpl to register prpl-aim and prpl-icq (instead of having two separate
libaim.so and libicq.so files).

-Mark