New plugin API
rlaager at wiktel.com
Fri Aug 9 01:54:50 EDT 2013
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:
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);
202 return PURPLE_PLUGIN_INFO(info);
830 plugin = gplugin_plugin_manager_find_plugin(id);
833 return plugin;
What is stopping g_object_unref() from immediately freeing info and
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the Devel