I've been working this summer on the One Laptop Per Child project. We do all our coding in Python, and I'm interested in game development, so my project was to help make game development for the platform easy to do, and the natural choice for Python game development is Pygame.

If you just run a Pygame app on the device, you get annoying behavior, and you don't get nice integration with the existing applications. The Sugar HIG requires the app to be wrapped as an "activity" and to have a certain toolbar at the top of the screen, and plenty of other things. So I've worked this summer on getting all those integration details worked out.

The most interesting thing is definitely the networking code. Here's an overview:

First, each laptop has two wireless cards. One card can be associated to an access point while the other talks to other laptops in the area directly in mesh mode (no infrastructure). In fact, the system is set up so that if one laptop can see the AP and another laptop, and the second can't see the AP, the second can get online (have its packets routed) by the first. This is all done dynamically and behind the scenes, which is super cool.

Each XO laptop when it's online resides within a certain neighborhood of other XOs. The neighborhood is defined by the aggregation of two sets of XOs: the set connected to the presence server, and the set that is "link-local" -- i.e., can be discovered via broadcasting on the local subnet. The presence server is an interesting beast itself -- it will contain the names and addresses of every XO that's online that it knows about, and each XO is configured to contact a certain presence server when it is activated. (Right now they all contact a central one at laptop.org HQ, so pretty much every laptop in the world appears in the same neighborhood.)

Now, here's the exciting part. Every Activity is mandated to have a Share button on its toolbar. When you click Share, the activity appears as an icon in the Neighborhood that you belong to. Now, anyone else can click on that icon, and they join that activity: the idea is that you are collaborating with everyone else who is joined to that particular activity. As people are joining activities, they appear "clustered" around the activity icon, as shown in this concept shot.

Now, this is all just barely starting to come together. But it's an incredibly cool concept -- collaboration on anything, at any time. The lower-level framework for this collaboration is actually in place and in need of debugging, but the basic principle works: when you click Share, everyone else sees your activity, and they can join it, and the activity launches on their machine (with your color scheme, 'cuz it's you who started it). The difficult part is the actual code within Activities to allow for effective collaboration, and this is the code that needs to be architected differently for each Activity.

We use D-bus for almost all our communications needs. Telepathy is the name of the text-layer communications protocol that resides on D-bus, and Tubes is the name of the data-layer protocol. When you join an activity, a Tube is (almost) automagically created for you. You just need to define the D-bus objects, methods, and signals, and send them flying across the Tubes in order to collaborate. And I've heard that some people have been working on a transparent "shared object" API so that if you're happy with asynchronous modification to your objects, you can just "share" them and changes are automagically shipped across the tubes.

For Pygame, I've selected a different system -- in fact, I must admit I've regressed a bit, down to the concepts of "send-message" and "broadcast-message". However, this is within the design philosophy of Pygame -- do what game developers expect. And in this case, game developers I think are used to that method of communication. You don't need to provide a UI in your Pygame game for presence or joining existing games, or anything. All you need to do is listen for a few new Pygame events. Because it's as easy as this: when the user shares your activity (either by clicking Share or by starting the game from the Neighborhood screen by clicking your icon), you get a CONNECTED event on the event queue. When somebody joins or leaves, you get JOINED and LEAVE events. When somebody broadcasts or sends directly to you, you get appropriate events. And you can asynchronously send any Pickleable Python object across (either broadcast to every participant, or send to a particular one) using simple method calls. I think -- hope -- that this is one of the easiest network interfaces for game development, and it was an incredibly easy API to construct using Tubes and D-bus and the underlying layer.

This is definitely one of the most exciting things about the XO laptop. It's an amazing project.