Going for gobjectification

[gillou.ray at free.fr]

On Mon, 22 Apr 2013 10:46:52 +0200
Tomasz Wasilczyk <tomkiewi at gmail.com> wrote:

> Hi,

Hi Thomasz, sorry for the late reply!

> I was pretty excited with detachable sessions project, so I looked
> sometimes at gobjectification thread. However, information at [1]
> doesn't contain too much details.

You’re totally right, thank you for pointing that out. I started adding
some technical documentation to the wiki page. Many of your questions
should be now be answered there.

> The first thing: is gobjectification the only one obstacle for
> detachable sessions (let's call it "DS")? Will it work when gobj was
> done? How amount of work is needed for DS after gobj was ready?

I must admit I don’t have a clear view regarding that. Yes, gobj is the
only obstacle for DS. A reasonable amount of work will be needed to get
DS basically working once gobj is done. But a huge amount of work will
be needed to get DS done entirely.

Let me clear up something. There are two DBus implementations. The
current one in the main branch uses dbus-glib. Not only dbus-glib is
pretty bad, but this implementation only exports functions, not data.
And it’s a pretty crude one. That’s why I rolled my own dbus thing
based on gdbus. GDbus is a much, much better library, and I think my
dbus implementation could also replace the existing one. But it only
works with gobjects.

So dbus needs gobj, while dbus is the “link layer” of DS. Once we have
gobj, DS code can be written quite easily, because the current DS
implementation makes it easy to transmit gobject properties, signals,
and to remotely execute methods.

> I'm also curious, how exactly DS works. Precisely, I don't know, why
> gobj is so important for [libpurple daemon] <-dbus-> [libpurple ui
> client] link. Is there any easy and standarized serialization, or
> remote execution for such?

Yes, exactly. DBus has a concept of object properties, methods and
signals. Gdbus makes it easy to transmit gobjects properties and
gsignals. And I also wrote a sort of libpurple layer that makes it even
more easy for our usage. Every of our gobjectified structs inherits
from the PurpleObject class, in which I put things like generic RPC
getters and setters, generic signal forwarding, generic RPC call etc.

> And the last: gobj is suggested as GSoC project, but there is no rough
> estimation for amount of work. I assume, that initial struct hiding
> task will take less than a week (they just have to be removed from
> API?). Is gobjectifying rather a tedious work (adding some metadata),
> or requires code re-designing? What are time estimations for a major
> struct gobjectification (let's say: PurpleConversation)?

I’d like people to answer this too! Things needs to be clarified,
and tasks broken down.

> Gillux: what's the chances for you for successfully completing gobj
> and DS task?

That’s a rather difficult question. To be honest, at the time I wrote
the mail that started this thread, I had a GSoC nostalgia and the
willing to make progress, but I don’t feel like I can do this alone
anymore. So, chances are pretty low currently.

		— gillux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://pidgin.im/pipermail/devel/attachments/20130429/cd6eb104/attachment.sig>