The GNOME Platform, Awn, and the Cloud

Benjamin Otte recently wrote about desktop-web integration in the GNOME desktop. It's kind of interesting that he calls himself "not web enabled", given that he's the main developer of the swfdec library and associated applications. I agree with most of what he wrote, but there are a few comments I would like to make.

Benjamin asks:

Why does dconf (or GConf) not store my settings in the cloud so it uses the same settings on my university login?

As I understand it, this is one of the features of Conduit. There's a bug in Awn regarding config synchronization via Conduit. I'm probably going to look into how that works when I resume work on the config interface for libdesktop-agnostic.

There is an erroneous statement in his post:

We don't even have a http library that knows cookies.

libsoup has had (non-persistent) cookie support since 2.23.1, and persistent support will be in 2.26.0.

And then there's the main point:

[GNOME is] doing a very bad job at integrating the web into the desktop. Apart from epiphany (and the weather applet), what application does GNOME ship that speak http?

I believe there are two main reasons for this: One is GNOME developers are not "web-enabled". [...] The other, related reason is that we don't have the software to do this.

In Awn-land, we have several web-enabled applets:

• arss
• comics
• digg
• lastfm
• meebo
• pandora
• rtm
• weather
• webapplet

In particular, webapplet is a work in progress framework, which will allow what is essentially an applet version of Mozilla Prism. It currently uses WebKit as the backend, although there is also a Gecko-based backend planned. The rest of the applets listed are written in Python. In particular, the digg, meebo, pandora, and rtm applets use the gtkmozembed Python bindings to view the respective websites. Here lies one of the problems of the web-enabling the GNOME platform. This library is acknowledged to be less than ideal. If you look at the source code of the applets, you'll see that there are some ugly hacks in order to make them work properly on Ubuntu systems. Webapplet is slated to replace that ugliness.

One of my side projects is a status aggregator applet. It's supposed to aggregate all of these social networking status feeds and also to sync all of your personal statuses. One of said social networking websites returns complex, site-specific HTML that obviously needs to be sanitized/canonicalized. The easiest (but not necessarily most memory-efficient) method of performing that task is to use the DOM. There is not currently a DOM library for the GNOME platform. There is a libgdom3 project (written in Vala) which I believe is being / will be used by the gnome2-globalmenu project, but it is unfinished. There is also an old, unmaintained library called gdome2 based on libxml2. I'm not even sure if anyone actually uses that library anymore (its last release was in 2003). I avoided using gtkmozembed and friends based on the experiences described above. I settled on a promising feature request for WebKit: a GObject/C DOM binding. (As an aside, the WebKit bug linked is a fascinating case study on several levels: conflicting coding standards, conflicting developer personalities, and some interesting coding/reviewing.) It's very nice - I can manipulate document fragments as if I were using JavaScript in a web page, among other things. I eagerly await that feature being committed to WebKit trunk.It is an important stepping stone when it comes to working with the web.

Another side project that I'm currently working on is a developer dashboard applet. It's kind of like the previous applet, except as applied to software projects. I was originally going to write it in Vala, which meant that I would have to write an interface to (at least) the Launchpad API, which meant implementing at least three specifications in Vala: OAuth, URI templates, and WADL. I finished the first two (I haven't yet decided whether to release my URI templates implementation as a separate library - the implementation plus the test app is 451 source lines of code), and WADL is a very complex specification. So, I decided to postpone working on the WADL library and instead am currently working on a prototype applet using Python and launchpadlib. Implementations for those three specifications and many others (including AtomPub) should be included in the GNOME platform if it wants to be web-enabled.

Re: Atom Protocol Exerciser (Ape) setup notes

Note: I had intended to post the first part of this on his blogDave Johnson's blog as a comment, but it rejected me twice. Apparently I write like a spammer.

That was a lot more complicated that I had expected; makes me wonder if I'm the first person (other than Tim, of course) to deploy the APE.

I deployed it locally a few months ago, while debugging my Atom protocol plugin for Trac. During that time, I wrote up some implementation questions (which Tim graciously answered) and the method I used to run it.

---

Incidentally, lately I was tweaking my particular implementation since Tim Bray had recently updated the APE to be compliant with the latest revision of the specification. My shebang line for go.rb changed from #!/bin/bash /usr/bin/jruby to #!/usr/bin/env jruby. It's still working fine, even if it's still a little slow.

I need to figure out how to fix some of the errors that I get. For instance:

18. ? Client-provided slug 'ape-61911' not used in server-generated URI.

I have no idea how to fix this. When I get a valid Slug header, I use it verbatim:

To server:

GET /trac/atom/wiki/ape-61911 HTTP/1.1\r
Host: localhost\r
Accept: */*\r
\r

Perhaps the following line is confusing the APE:

Location: http://me.malept.com/trac/xmingw/atom/wiki/ape-61911\r

Additionally, apparently my plugin currently has some problems with the new multi-post app:edited test, but so far I think it's something wrong in my code as opposed to being a bug in the APE. I'm going to try to take a look at it tonight.

Ego++

Typically, I'm not one to toot my own horn too much, but I'm rather excited about this. Because of my earlier post, two things happened:

1. The APE was changed to support HTTP status 204 No Content, and
2. the APP draft specification was changed to clarify (via text and examples) that non-200 OK responses for PUT/DELETE were acceptable.

I think it's awesome that I could (somewhat indirectly) influence a standard like that. At the very least, it gives the ol' ego a little boost.

Re: Genshi Filters for Venus; Genshi + Trac-AtomPP

This news is excellent. One of my side projects (although, it was pretty low on my list) was to figure out how to use Genshi templates in Venus. I started out by copying the Django template code/unit tests and adapted them for Genshi. However, I got stuck getting some of the unit tests to pass (_item_title and _config_context). Perhaps sometime this weekend I can see how this particular implementation works.

Speaking of Genshi, I just noticed that they had released version 0.4. Hopefully, this will help me resolve the last APE error in my Trac-AtomPP plugin — adding app:edited elements to relevant entries and sorting by that property.

While I'm thinking about it (this really seems to be turning into a stream of consciousness post), I'm not exactly sure how to page the collection efficiently, considering that Trac creates the wiki page list via a generator. Right now I'm just putting everything into one feed, but obviously that doesn't scale very well.

trac-atompp progress; APE questions

I'm working on (among other things) finishing up wiki support in my trac-atompp plugin. I'm nearly done, I think. In order to make sure it's "valid", I'm using Tim Bray's APE (albeit from CVS). However, I've got a few questions about some of the errors:

8. ! 53 of 53 entries in Page 1 of Entry collection lack app:date elements.

From the source, it looks like it should actually say app:edited. But, why is it giving an error? According to draft 14, section 10.2, Atom Entry elements in Collection documents SHOULD contain one "app:edited" element, and MUST NOT contain more than one. Perhaps the messages should conform to RFC 2119 instead of lumping in all of the SHOULDs with the MUSTs, or something.

49. ? Can't update new entry with PUT: No Content [Dialog]
50. ! Couldn't delete the entry that was posted: No Content [Dialog]

I don't really understand why HTTP status code 204 (No Content) isn't allowed for either PUT or DELETE, seeing as RFC 2616 says that it is a perfectly valid response for both actions.

Trac-AtomPP progress, 2007-01-23

I finally got myself out of my Trac plugin coding slump. Genshi is really making this a whole lot easier; I don't really know why I was manually generating XML from trees in the first place.

I am very grateful for the existence of Joe Gregorio's Atom Publishing Protocol test suite. There are only a couple of nits about it — first, it doesn't seem to play well with Multi-version installs of wxPython (seems to require 2.6, perhaps 2.5 [I only have 2.4 and 2.6 on my computer]), so I cooked up a really simple patch for that. Secondly, my wiki collection feed generates some warnings via Feed Validator, but in the logging pane, it records them as errors. Since it doesn't affect the functionality, I merely consider that a minor usability bug. But, this really doesn't seem to be meant for end users, so...whatever.

Anyway, for my capstone, I'm only working on the wiki part. GET is done, and POST is nearly done. DELETE is done in theory (haven't tested it out yet), and PUT still needs to be converted. POST and PUT now require some implementation of ElementTree to be installed, in order to parse the Atom Entry input. As an aside, ElementTree's find*() methods are really poor substitutes for XPath. Also, this implementation utilizes the Atom MIME type parameter draft whenever possible.

Reminder: Bazaar URL is: http://bzr.malept.com/trac-atompp

Several items

The last post was 1.5 months ago, awesome. Anyhow, here are some thoughts on stuff I've done/explored in the computer realm during that time:

• Beryl is awesome. Too bad it doesn't play well with tvtime, or else I'd permanently enable it and all the associated settings. Also, my video card is one of those crippled ones (ATI Radeon 9250SE), so it's a bit slow as well.
• My capstone project is in full swing. I've mostly stopped using my hand-rolled Atom parser/generator, since I got stuck on how to implement extensions. For generation, I've switched to using Genshi templates. Genshi has a pretty nice templating language for both XML and text based documents. For parsing, I think I'm going to use lxml or ElementTree, depending on how well XPath is supported.
• Given the amount of attention that OpenID has been given in the blogosphere lately, I was thinking about how it could be used to integrate with the UWNetID system. Unfortunately, I found that it was rather difficult to modify the current implementations in order to add such support. So, I'm currently writing a PHP5 class + mini-application to be an OpenID server. So far, I have the association mode completed, and the checkid modes are in progress. I am proud of myself for actually implementing the Diffie-Hellman key exchange, since while I am fascinated with cryptography, my math skills in that area are...lacking. It's also nice to refresh my PHP skills, as I haven't programmed in PHP5 (which gives you some idea as to the last time that I coded in PHP).
• Over winter break, I attempted to port modular X to MinGW, as the Xming project (which is awesome) uses the old, monolithic build process. I've built all the Xorg server (and its dependencies) successfully, except that the OpenGL code for Windows has not been updated with the rest of the server's codebase. That sort of modifications are pretty far out of my porting abilities, unfortunately. This project also gave me some experience with git. My take: it's extremely annoying to use git directly — use a frontend to it such as cogito instead. My personal preference is still Bazaar, though.
• I wrote a Python module in C for my on-again, off-again, DC client project. I have a post on that sitting in my queue and will post it at some point when I finish and/or remember it.
• I eagerly await the day when Deepest Sender supports the GData Blogger API. Maybe in the spring, if it's not there, I'll write it.
• Oh right, the new URL for this weblog is http://blogger.malept.com/.