Have just completed a working implementation of a DBUS Proxy object for OLPCGames that allows you to define networking "servers" as ExportedGObjects then call/subscribe to them from within your Pygame event loop (without threading-related crashes).

The proxy avoids having client callbacks happen in the GObject mainloop, which could cause segfaults/cores in your Activity when you happened to call a Pygame-display-triggering method. Instead the proxy arranges for a GObject side reply_handler/error_handler to call your Pygame-side callback/errback. The proxy also enforces the use of the asynchronous API when interacting with DBUS objects, avoiding the other major source of segfaults/cores in OLPCGames activities (DBUS does not like having a synchronous call happen in a thread other than the GTK mainloop).

I know, I know, what am I doing spending time on this stuff when I should be out finding a job and/or drumming up clients? Well, I really wanted to be able to cover Telepathy usage from Pygame for the tutorial at PyCon, and as it stood, it was simply broken and not worth documenting or teaching. I'm now okay with teaching it as a workable approach to networking.

At the moment you still have two different "environments", the GTK-side server object, and the Pygame-side client object. I considered making an API to allow you to define your server objects on the Pygame side and have a generated object which would forward events to your Pygame-side object... but that just seemed a little pointless. The GTK-side server object seems a reasonably expressive way to set up a new server.

Of course, at some point the whole approach should go away and we should have a single thread of control... but until someone has the time to make the GTK backend for Pygame production-ready, we're likely going to stick with the X-embed based structure. At that point we can just replace the proxy objects with the proxy objects they proxy and hopefully we won't need to recode the client code.