Telepathy Wrapper Lands in OLPCGames (Network asynchronously from your Pygame-side code...)


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.

Comments

  1. Andrew Clunis

    Andrew Clunis on 02/25/2008 4:52 p.m. #


    Hey Michael!<br />
    <br />
    Remembering all of the olpcgames/glib/telepathy-related suffering from the November Game Jam, I'm very happy to hear about this.<br />
    <br />
    Also, I thought you were working for OLPC now...?

  2. Mike Fletcher

    Mike Fletcher on 02/25/2008 8:37 p.m. #


    Hi Andrew,<br />
    <br />
    The code here is really just the pattern we worked out for Productive with the abstractions necessary to avoid the crashing coded into the wrapper instead of the client code.<br />
    <br />
    As for working for the OLPC, I was working for them as an external consultant via my company. As of January 1st I have moved them to non-charged Open Source project status. That means I have far less time to work on the project, but it is personal time, instead of company time, so that I can work on paying projects during company time.<br />
    <br />
    This way I can't wind up killing my personal finances by letting my contributions grow to fill all available time (since it's not "business" any more it can't be happening during business hours). During December I spent every waking hour on the project, completely setting aside all of my other clients (and almost everything else). With a 10hr/week cap on billables I wound up taking a bath on the month. I can't allow that kind of situation to occur again if I want to remain solvent, and this separation makes it unlikely to reoccur.<br />
    <br />
    Of course, I've actually been working on the PyCon tutorial during "company time", but that was a prior commitment, and people deserve a good tutorial, having paid their money to the conference. The fact that it should make it easier for people to code with OLPCGames in general is just gravy.<br />
    <br />
    Have fun,<br />
    Mike

Comments are closed.

Pingbacks

Pingbacks are closed.