Some aspects of the GObjectification approach

[Ankit Vani]

Today, I had an interesting conversation with grim regarding
GObjectification. I would like to share what I discussed with the
community and would appreciate feedback and suggestions to help plan
my approach.

grim had created a spreadsheet to track the progress of
GObjectification in the gobjectification branch. It has not been
updated for a long time since the branch is dead. However, I found it
an effective way to plan and keep track of the progress of
GObjectification. I have forked this spreadsheet and will be using it
for my project:
https://docs.google.com/spreadsheet/ccc?key=0Apn-OqBMZy6DdEZkVTNBX09IellIajBmUnhkcE5HU0E&usp=sharing
(currently unmodified from grim's version).

He also has a docbook for GObjectification located at
http://guifications.org/~grim/html/ which goes into more detail than
the spreadsheet. I found it quite helpful and can help me a lot in
this project. Please suggest if you have anything to add regarding the
contents of this docbook.

The following are some of the suggestions given by grim regarding
various aspects of GObjectification:


1. PurpleObject
---------------

In my proposal, I suggested using PurpleObject as a base to all purple
classes. But PurpleObject doesn't really buy us anything and wastes
memory instead. The objects can inherit GObject directly and any
mechanism that would require PurpleObject would just be more flexible
by using GObjects instead.

GtkObject was removed in Gtk3 since they had a similar realization.


2. Data fields
--------------

We do not need to have protocol data and UI data fields on objects.
For that, we can use subclasses. For example, we can have GObject <-
PurpleBlistNode <- PurpleBuddy <- XMPPBuddy. If we cannot subclass, we
can use or g_object_set_data().


3. Connections
--------------

Right now, the prpls need to check what's set on their accounts and
then build their own connection accordingly. This should be done in
the core. Thus, for connections, we can follow the decorator design
pattern as demonstrated:

Suppose we have an XMPP connection, and we want to use it over SSL,
over a SOCKS5 proxy. The core wraps the instance of the XMPP
connection in an SSL connection, then in a SOCKS5 proxy. Now, the prpl
doesn't have to care about SSL or SOCKS5.

The core then only holds onto the SOCKS5 proxy, and when it's connect
method is called, it connects to the proxy, then it calls the connect
method on it's child connection, which is the SSL connection. The SSL
connection then establishes the SSL connection over the proxy
connection that already exists. Then it calls the XMPP connection and
connects you to the XMPP server over the SSL connection that's running
through a SOCKS5 proxy.


4. Plugin API
-------------

A part of my project is to implement a GObject-based plugin API. The
requirement was to be able to have plugins that depend on each other,
can be written in other languages, can register types into the GObject
type system. When researching this, I came across an existing
implementation called libpeas. However, I found libpeas to be
overkill. There were also some issues such as requiring a separate
file for author and loader information. I decided against libpeas
because I didn't want complicate the API as it stands today. So I had
left it out of my proposal, and had proposed a simpler plugin API that
satisfied all requirements.

However, grim has already created a simple library to provide this API
- gplugin (https://bitbucket.org/rw_grim/gplugin). Although it only
supports native plugins right now, a python loader can be developed.
Like libpeas, gplugin uses GObject-introspection, so adding languages
only requires writing a loader for a language that has GObjects.

Thus, for GObject-based plugins, we can use gplugin.


5. Protocol interface
---------------------

As for the protocol interface, rather than having a single interface
that all plugins implement, a better way to do this would be to have
PurpleProtocol as an abstract base class, and interfaces such as
BuddyIconSpecIface, WhiteBoardIface etc. Protocols can inherit
PurpleProtocol and implement the interfaces that apply to them.

Instead of checking if particular function pointers are there, we can
just do something like PURPLE_IS_WHITEBOARD_PROVIDER(protocol).