New plugin API

[Gary Kramlich]

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
stuff?


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:
> 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
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130809/22a11371/attachment.html>