Going for gobjectification

[Tomasz Wasilczyk]

Hi,

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.

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

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

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

I wish that questions will shed some light on these projects.

Tomek

[1] https://developer.pidgin.im/wiki/GSoC2010/DetachableLibpurple

2013/4/18  <gillou.ray at free.fr>:
> Hello,
>
> I’d like to give a try at doing this gobjectification work, and I have
> a few questions regarding this. First let me point out that it’s not
> gonna be a GSoC project because I’m not a student anymore. (And I have
> huge doubts that any student is ever going to do this.)
>
> My main motivation is to eventually bring my detachable sessions branch,
> which rely on a proper gobjectification, towards a usable state. I
> don’t have a deep knowledge of gobject nor libpurple, but I already
> hacked with both to a fair extend. Actually did more gobject/glib than
> libpurple, so I’m not that confident about the actual amount of work.
> In particular, I saw some of you treating gobjectification and struct
> hiding as a rather tedious work, and I’d like to know what actually
> makes it so difficult. Could anyone elaborate on this?
>
> I’ve been told that it would be smarter to start from scratch based on
> the main branch than trying to merge the existing outdated
> gobjectification branch. Anything under cpw.gillux would do? Or some
> non-cpw branch so that others may join the party?
>
> Taking lessons from the previous gobjectification work, it seems we
> should really try to merge things with the main branch often, because
> otherwise it becomes a pain to merge and eventually gets dropped,
> right? Or is it a pain to merge anyway because gobjectification tends
> to blow everything up by nature?
>
> What would be the best merge strategy? Gradually merge gobjectification
> work to main (like one PurpleStuff struct after the other), or regularly
> merge main to gobjectification?
>
>                 — gillux
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>