One of the novelties in the airport lounge at Narita was a beer pouring machine. It manages to consistently pour a good glass of beer every time. You start by placing the glass in the machine: When you press the start button, it tilts the glass and pours the beer down the side of the glass: After filling the glass the machine tilts the glass upright again and some extra foam comes out of the second nozzle: Not only was the machine fun to watch, but the beer was okay too.
I am at Narita Airport at the moment, on the way to Boston for some of the meetings being held during UDS. It'll be good to catch up with everyone again. Hopefully this trip won't be as eventful as the previous one to Florida :)
Most people have probably seen or used OpenID. If you have used it, then it has most likely that it was with the 1.x protocol. Now that OpenID 2.0 is close to release (apparently they really mean it this time ...), it is worth looking at the new features it enables. A few that have stood out to me include: proper extension support support for larger requests/responses directed identity attribute exchange extension support for a new naming monopoly I'll now discuss each of these in a bit more detail Extension Support OpenID 1.1 had one well known extension: the Simple Registration Extension. An OpenID relying party (RP) would send a request with an openid.sreg.required field, and get back user information in openid.sreg.* fields from the OpenID Provider (OP). The RP and OP would just need to know that "openid.sreg" fields means that the simple registration extension is being used. But what if I want to define my own extension? If my RP sends openid.foo.* fields, how does the OP know that it refers to my extension and not some other extension that happened to pick the same prefix? OpenID 2.0 solves this problem by borrowing the idea of name space URIs from XML. If I am sending some openid.foo.* fields in an OpenID message, then I also need to send an openid.ns.foo field set to a URI that identifies the extension. This means that a message that sends the same data as openid.bar.* fields should be treated the same provided that openid.ns.bar is set to the extension's name space URI. As with XML name spaces, this allows us to piggy back on top of DNS as a way of avoiding conflicts. Large Requests and Responses OpenID 1.1 uses HTTP redirects as a way of transferring control between the RP and OP (and vice versa). This means that the upper limit on a message is effectively the same as the smallest upper limit on length of URLs in common web browsers and servers. Internet Explorer seems to have the lowest limit—2,083 characters—so it sets the effective limit on message size. For simple authentication checks (what OpenID was originally designed for), this is not generally a problem. But once you start to introduce a few extensions, this limit can easily be reached. OpenID 2.0 allows messages to be sent as an HTTP POST body which effectively removes the upper limit. The recommended way of achieving this is by sending a page to the user's browser that contains a form that posts to the appropriate endpoint and contains the data as hidden form fields. The form would then get submitted by a JavaScript onload handler. Directed Identity For OpenID 1.1, the authentication process goes something like this: the user enters their identity URL into a form on the RP the RP performs discovery on that URL to find the user's OP. the RP initiates an OpenID authentication request with that OP. With OpenID 2.0, the discovery process may tell the RP that the…
Last week I was in sunny Dunedin for a Launchpad/Bazaar integration sprint with Tim and Jonathan. Some of the smaller issues we addressed should make their way to users in the next Launchpad release (these were mainly fixes to confusing error messages on bazaar.launchpad.net). Some of the others will probably only become available a release or two further on (mostly related to improving development workflow for branches hosted on Launchpad). My previous trip to New Zealand had also been to Dunedin (for last year's linux.conf.au). Since then they'd replaced all the coins for denominations less than NZ$1. Other than being less familiar to Australians, the smaller coins seem like a good idea. They don't seem to have taken Australia's lead in making the $2 coin smaller than the $1 coin though.
It is probably old news to some, but Google have put up an information page on the upcoming Australian Federal Election. The most useful tool is the Google Maps overlay that provides information about the different electorates. At the moment it only has information about the sitting members, their margin and links to relevant news articles. Presumably more information will become available once the election actually gets called. Presumably they are planning on offering similar tools for next year's US elections and this is a beta. So even if you aren't interested in Australian politics, it might be worth a peak to see what is provided.