GCI Low Hanging Fruit

I have to admit I'm pretty surprised that at halfway through Google Code-In 2011 only about a quarter of the tasks we posted for the first half have been completed or in-progress. Further, most of the tasks thus far haven't been coding tasks.

I'm going to publish here a list of what we consider "low hanging fruit"; coding tasks which are fairly easy to get started with. If you're a student age 13-17 these would be an easy way to earn a Google tshirt and some cash. All of these tasks deal with OpenGL rendering, usually just arrays for points and lines/triangles which connect the points. There's a lot of examples in the code already for this and numerous tutorials on the web (such as NeHe).

Simple Rendering

We have 2 new tasks listed for rendering simple models; Camera and Light. Camera is very simple, while Light can be as simple or complex as you want to make it.

Shapes Rendering

We have 3 tasks for rendering shapes, Box, Room, and Sphere. Any of these could be knocked out in a few hours even without prior OpenGL knowledge.

Joints Rendering

We have 6 new tasks up for rendering joints; Ball, Fixed, Hinge, Piston, Slider, and Universal. Joints (soy.joints) connect two bodies such that they can only move in respect to each other in a certain way, such as a door hinge or piston. These are all documented with graphic depictions. This is slightly more complex than the simple rendering tasks (above) in that there's two pieces to each joint and they can be rendered as either wireframe or solid (with provided materials).

As always, we're on IRC if a student wants to discuss these or other tasks.

PyTTY 0.3

Continuing my annual end-of-year coding sprint, I just released PyTTY 0.3.

PyTTY is a Python serial communication package I started last year after a friend said he couldn't use Python 3 yet because pyserial wasn't ported. The point of writing this was to show him that he didn't need an ancient, bloated, poorly-maintained package to do something as simple as serial communication.

What I wrote over an afternoon turned out to be a little over 100 lines of fairly useful code which I've since used in quite a few microcontroller projects (eg, Arduino). Its by no means complete, the only setting is baud rate and there's no Windows support, but its done everything I've needed it to over the last year. The only problem that's been reported is poor documentation which this release aims to fix. It includes a short code example ("pydoc pytty.TTY") which runs on both legacy Python and Python 3.

PyTTY 0.3 is under 135 lines of pure Python and relies only on the Python standard library. If there's a feature you need which this doesn't have either email me a patch or a feature request so I can add it. The Mercurial repository is http://hg.pytty.org/pytty.

NodeTree 0.2 Released

I just shipped NodeTree 0.2.

This version will not parse an XML stream. All it contains are some basic types representing XML nodes such as Comment, Document, and Element. As promised, text is also handled as a node but uses standard Python strings (UTF-8 strings/bytes and unicode). These should all be fairly intuitive to use.

The magic is the XML data is being managed in C using a libxml2 DOM tree but accessed through a Pythonic object-oriented API. For example, in DOM each node may have exactly one parent - in NodeTree a node may be added to any number of parents with a separate DOM node and context for each.

I started this project because the existing XML packages for Python proved too difficult to use with XMPP. Fritzy's SleekXMPP uses lxml but had to jump through several hoops to get stream parsing to work, looking over his work I certainly didn't want to repeat it with Concordance-XMPP.

Beyond this the leading XML API for Python, ElementTree, includes several unfortunate design decisions that make it frustrating to use in the best cases and unusable in others. A full list of why can be left for another time, but the difference to NodeTree can be described in their names - ElementTree is a tree of XML Element nodes with other kinds of nodes either silently dropped, mangled, or made available in bizarre ways (eg, .text and .tail). In contrast, NodeTree provides XML data as a tree of nodes starting with the Document node and includes comment and text nodes in its tree. I plan to provide 100% XML 1.0 support in a future release while maintaining a clean, simple, and intuitive API.

Storing XML data in libxml2 DOM format gives us a few advantages over other XML libraries. First, we'll have XPath, XInclude, and XSLT available without having to convert the data between formats. Second, Python objects only need to be created for nodes Python wants a reference to so when we get to parsing data this will happen much faster and with less memory.

At version 0.2 NodeTree is still in its infancy but some of its API can be demonstrated. Here's a short example:

Python 3.2.2 (default, Oct  3 2011, 00:20:58) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import nodetree
>>> doc = nodetree.Document()
>>> doc.append(nodetree.Comment(' Start '))
>>> doc.append(nodetree.Element('data'))
>>> doc.append(nodetree.Comment(' Fini '))
>>> doc[1].attributes['thing'] = 'normal'
>>> doc[1].append(nodetree.Element('record'))
>>> doc[1][0].append('First') 
>>> doc[1].append(nodetree.Element('record'))
>>> doc[1][1].append('Second')
>>> doc
<?xml version="1.0"?>
<!-- Start -->
<data thing="normal">
  <record>First</record>
  <record>Second</record>
</data>
<!-- Fini -->

NodeTree 0.2 is tested to work with Python 2.6, 2.7, 3.1, 3.2, and 3.3-pre. The next release is intended to support basic file and stream parsing.

XMPP on the web

A short thread on G+ has prompted this longer sharing of my vision for XMPP on the web.

For XMPP use on a website we currently have BOSH and, in an extreme-alpha state, XMPP over websockets. The advantage of websockets is obvious, BOSH is a high overhead protocol that we'd all rather not have to use, however both have the same problem: you either must share your login credentials (and thus access to your account) with every website you use a single account with, or must create a new account (JID) for every XMPP-based website you use.

Oauth2 for XMPP might be a partial solution to this by requiring your authorization through a central identity site and using the resulting token for logging in, however, you're still opening yourself up to the 3rd party website accessing your roster, sending spam messages on your behalf, and potentially worse. All this really gives you is the ability to later disable access to websites who misuse your account.

This is the crux of the issue: when using an Javascript library provided by a website and using a proxy provided by that website, whether BOSH, websockets, or otherwise, you're giving that website unlimited access to your account. I have not seen a workable proposal to solve this and until this is solved XMPP cannot see widespread use on the web.

I'm proposing that we solve this by putting XMPP in the browser, either directly or through a plugin. Expose a standard javascript API for allowing websites to use an XMPP connection along with a security model which gives users control as to what a website is allowed to use their connection for. Ie, if a script on a website wants access to their roster the user will be prompted for it, if they want to join a MUC room display a standard prompt for that. Browsers can have multiple XMPP sessions at once and allow the user to select which account they'd like to use with an XMPP-enabled site.

This is just some early ideas, I'm nowhere near implementing this though I think the conversation would be useful to get started.