New plugin API

[Ankit Vani]

Hi Eion

Thanks for your feedback! :)

On 9 August 2013 07:38, Eion Robb <eion at robbmob.com> wrote:
> I think that protocols should extend from PurplePlugin still... most of that
> stuff in the PurplePluginInfo object is needed in a protocol, including
> dependencies, names, icons, versions etc and to duplicate that in a
> PurplePluginProtocolInfo would be yucky.  Or maybe I'm missing something
> about the encapsulating thing you were talking about... a PurplePlugin
> contains PurpleProtocolPluginInfo's?  If so, are they free'd when the plugin
> is unloaded?

Do protocols need to worry about dependencies by themselves? The dependencies
can be set by the plugins that contain the protocols. As for icons, I think a
protocol will handle that and has nothing to do with the plugin itself. I have
duplicated ID, name and actions for protocols. That simply lets us give IDs and
names to protocols while plugins can have their own IDs and names. For example,
the 'yahoo' plugin can have provide the protocols 'yahoo' and 'yahoo-jp' (I'm
not much familiar with the prpl stuff), that it adds on load and removes on
unload. And protocol actions are different from plugin actions - they go to a
different menu and need a connection parameter.

A plugin has to call purple_plugins_add() on load (where you would also allocate
user splits, options and actions) to add a protocol to the core, and
purple_plugins_remove() on unload to remove the protocol from the core (remove
automatically frees what you allocated in load).

> What's "PURPLE_ABI_VERSION"?  If I wanted to say my plugin works on version
> 3.0.0 onwards, but I'm building on 3.2.1 source, what value would I use?

PURPLE_ABI_VERSION is a convenience macro that returns an ABI version using
PURPLE_MAJOR_VERSION and PURPLE_MINOR_VERSION. If you want to support ABI 3.0.0
onwards, you would use PURPLE_PLUGIN_ABI_VERSION(3, 0)

However, I am wrong to use the "abi_version" property for this, since it is the
required ABI version of GPlugin. This should probably be something like
"purple_version".

> If I wanted to sub-class a protocol (e.g. make a 'new' xmpp-based protocol),
> how would I do so in the new model?

I haven't started GObjectification of protocols yet. Protocols are still more or
less what they used to be right now, a PurplePluginProtocolInfo struct instance.
I'll be working on protocols after plugins are done.

> Are GPLUGIN_PLUGIN_INFO_FLAGS_INTERNAL and
> GPLUGIN_PLUGIN_INFO_FLAGS_LOAD_ON_QUERY actually part of GPlugin, or are
> they part of libpurple (and should thusly be renamed)?

They are part of GPlugin, and "flags" is a GPluginPluginInfo property.

> Your comment about "A plugin is deemed to not be loadable if..." seems to be
> a bit light on details, eg "The ABI version requirement for the plugin does
> not match" match what?  Are we moving away from the backwards-compatible
> thing, or did you mean to say that the ABI version has to be
> less-than-or-equal-to what the UI has been compiled with?
> What happens if two plugins with the same id's try to be loaded at the same
> time?

This is similar to the 'unloadable' member of the original plugin API. It was
TRUE if a plugin is not possible to be loaded because, for example, the plugin
has a newer ABI requirement or doesn't have an ID etc. Instead of using the
negative, and introducing confusion between unload-able and un-loadable, I have
chosen plugins to be 'loadable', unless they are not.

For example, if a plugin needs 3.1 and we are loading it on 3.0, the plugin
would be queried but its status would be that it is not 'loadable'. In a UI you
will be able to see the reason for it not being loadable - that the plugin's ABI
version does not match (3.1 needed).

I guess this still needs a little work though.

> If a plugin depends on another one, is that one loaded first, if it hasn't
> yet been loaded?  Are we also able to specify a version of plugin that we
> depend on?

Yes, if a plugin depends on another one, all the dependencies are loaded before
the plugin itself loads. This is handled by GPlugin. However, there is no
obvious way to specify a version for the plugin required.

In the plugin's load function, you could get the dependency plugin by
purple_plugins_find_plugin(dependency-id), and then check its version by
purple_plugin_info_get_version(). If the version is incorrect, return FALSE, and
the load will fail.

> Should the plugin "category" property be translated, or are they id's that
> the UI translates?

Honestly, I haven't decided this for sure. It is more of a proposal at this
point. I was thinking it to be a translated name. For example, if you choose a
category to be "Protocol", it can be listed under "Protocol plugins" in the
plugins window.

Please let me know if you have better ideas for this.

> Why have purple_plugins_find_with_name() and
> purple_plugins_find_with_basename()  been removed?  A quick google search
> shows that they're being used by UI's and plugins.

I didn't think they are really necessary. You could just find plugins by id
instead of by name. And I couldn't think of a usecase where you'd want to find a
plugin by basename.

I think existing plugins should be able to use find by id or filename instead of
these functions. If there is a good usecase of these, please let me know.

                                                                         - Ankit