GObjectification projects proposal, and GObject-based plugins API

[Ankit Vani]

I am working on a proposal for GSoC for GObjectification projects.

Pidgin has been wanting to adopt GObjects for quite some time now, and the
very interesting detachable sessions project can be made usable when this feat
is accomplished.
However, the gobjectification branches seem to be untouched for ages.
Since this is an important milestone for libpurple/pidgin/finch, I wish to work
on it and get involved with the pidgin community.


What my proposal will involve:

- Gobjectification of some core structures of libpurple, pidgin and finch

    Constructs such as the buddy list and conversation interface will be
    gobjectified. A significant amount of code redesigning around the GObject
    will be done along with this. I will be working alongside the community and
    my mentor for decisions regarding redesigning crucial bits.

- Remodeling the plugin API around GObject (coming to this in a bit)

    The current plugin API will be replaced with an API based on GObjects.
    There are a number of ways this can be implemented. I have discussed these
    methods below.
    Some existing plugins will be ported to the new plugin API.

- Protocol plugins will be an implementations of a protocol interface

    A GObject-based interface will be created for protocols. The protocol
    plugins will implement PurpleProtocolIface, which will provide a common
    interface to work with different protocols.
    Some existing protocols will be ported to the new protocol API.


For the new plugin API, I have determined the following possible ways to do
this:

(1) The current PurplePlugin becomes a GObject, and all plugins become objects
    of PurplePlugin.
    This approach is the easiest to implement since it is most similar to what
    is currently implemented.

(2) The current PurplePlugin becomes a GObject, and all plugins define their
    own type deriving from PurplePlugin.
    This approach gives plugins freedom to define its own members and
    extension points for other plugins. This seems to be a more intuitive way
    of dealing with plugins for a gobjectified plugin system.
    It will require a little more work in porting the existing plugins to
    the new API.

(3) Use a plugin API library such as libpeas.
    libpeas is an existing gobject-based plugins engine, and works in the same
    manner as (2). It supports multiple extension points and on demand (lazy)
    programming language support for C, Python and JS.
    It will require the most changes to the current plugin API, the existing
    plugin code and also the directory structure - every plugin needs it's own
    directory with a .plugin file that declares it's information (such as
    name, author etc).

I would like to gain insight into what the developers think about this, what
you would prefer and why.


It would also be kind of you to provide feedback and other suggestions so that
I can improve my proposal.

                                                        -- Ankit Vani (ankitkv)