New plugin API
grim at reaperworld.com
Fri Aug 9 02:04:04 EDT 2013
I'm not against relicensing, but I'd prefer to stay with v3. My reasoning
in picking GPL vs LGPL was to only allow it in FOSS.
I misunderstood Richard on IRC. So yeah, what's going on with that unref
On Fri, Aug 9, 2013 at 12:54 AM, Richard Laager <rlaager at wiktel.com> wrote:
> 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);
> 200 g_object_unref(info);
> 202 return PURPLE_PLUGIN_INFO(info);
> 830 plugin = gplugin_plugin_manager_find_plugin(id);
> 831 g_object_unref(plugin);
> 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.
> > 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?
> Devel mailing list
> Devel at pidgin.im
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel