New plugin API

[Richard Laager]

On Fri, 2013-08-09 at 01:07 +0530, Ankit Vani wrote:
> GPlugin has been added as an external dependency for libpurple.

GPlugin is currently GPLv3+, while libpurple is GPLv2+. This will
(according to the FSF interpretation, at least) effectively change
libpurple (when compiled with plugins) to GPLv3+.

We either need to be okay with this change, not use gplugin, or convince
Gary to change gplugin's license, possibly to one of the following:
LGPLv2+
LGPLv2.1+
LGPLv3+
GPLv2+

Gary, if you're open to relicensing, I suggest you choose from LGPLv2+
(to match glib) or LGPLv3+ (if you really like the "v3" changes).


> 3. Memory management becomes a problem with needing to remember to unref
> returned GPlugin objects and lists all the time, since the rest of the
> GObjectified libpurple does not ref and unref unless necessary.

Can you discuss this a little more?

I find the following code highly suspect, though Gary said it was fine
(but I don't understand how):

199 	info = gplugin_plugin_get_info(plugin);
200 	g_object_unref(info);
201 
202 	return PURPLE_PLUGIN_INFO(info);

and

830 	plugin = gplugin_plugin_manager_find_plugin(id);
831 	g_object_unref(plugin);
832 
833 	return plugin;

What is stopping g_object_unref() from immediately freeing info and
plugin, respectively?


> A plugin is also not loadable if it does not return an info instance. However,
> purple_plugin_get_error() will return NULL in this case because there would be
> nowhere to store the error.

purple_plugin_get_error() treats purple_plugin_get_info() returning NULL
as an assertion failure--you call g_return_val_if_fail(). If that's a
scenario that can occur for reasons outside of libpurple's control, you
should use an explicit check. Then, you can just return a (translated)
fixed string describing the error.

And purple_plugin_get_error() probably should return a const gchar *,
right? I assume the caller isn't supposed to modify that value.


> Protocol plugins are to be both internal and load-on-query.

I assume you mean *in-tree* plugins which provide protocols. Did you
decide against just always compiling those statically, and if so, why?

-- 
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20130809/41288631/attachment.sig>