There are two traditional models for parsing XML, SAX and DOM based methods. These are both pretty heavyweight technologies but for the work i’m doing on web services I want something a bit lighter and a bit simpler to extract just the information I care about. Inspired by the Beautiful Soup HTML screen-scraping library I sought to build an API that lets you trivially find the content you are looking for.

Here is an example:

n = rest_xml_node_find (root, “photo”);
while (n)
{
  title = rest_xml_node_find (n, “title”);
  printf (“%s”, title->content);
  n = n->next;
}

Fundamentally the libREST XML parsing strategy turns the XML into a tree of nodes, where a node can have siblings (accessed through a next pointer) or childen (stored in a hash of child tag name to node). This combined with a simple tree walking function (rest_xml_node_find) results in very minimalistic code for extracting just the content you care about.

You can find the source code for libREST in git.

Firstly (the smaller of the two) i’d like to see a revamping of the Evolution client libraries, ECal & EBook, in particular ECalComponent is horrible. The work that Chris and I have been doing on libjana is showing some of the direction that such a library for accessing calendaring could go. This requires an ABI & API break to do this effectively (hence being a 3.0 thing.)

Ross has also been doing sterling work on the server side of things by migrating the eds-dbus fork into the mainline. This is now basically just waiting on the migration to git and a double review of the calendaring code.

The second and more significant thing that I care about is that I think we need to bring web services closer into the desktop. I’ve been persuaded that desktop applications are not dead but I think we need compelling, transparent and easy ways to integrate with “cloud” services. In particular we are entering an age of “almost always on” connectivity. Many people already find little use for their computers if they are not connected to the Internet. However since the omnipresent and omni-reliable 3G/wireless/wimax utopia is not yet with us we live in a world where we get connectivity in bursts as we travel, socialise and live. Our platform should cunningly pull down interesting content when the user is on cheap and reliable connectivity which they can then peruse when offline or on an expensive and unreliable connection.

A project that Ross and I have been working on at Intel to bring social networks to the desktop/mobile is called Mojito. I’ll cover this in more detail soon.

Our hero: Ross Burton

So, I did some research, read up on RESTful. And thought yay, lots of services are claiming to be RESTful, let’s see if we can come up with some kind of service description language that we can autogenerate code from (ala, dbus-glib). Turns out that very few services actually adhere to this RESTful definition and my attempts to produce some kind of description language resulted in more lines of XML than code, hmmm.

Anyway, I persevered and looked at building an API that I would fine easy to drive RESTful web services with. After a few iterations I decided upon designing something with a somewhat Cairo-esque API.

Marco thinking RESTful thoughts.

The API is comprised of two parts, the first half is for making the requests (and is based on libsoup.) Here is an example:

  proxy = rest_proxy_new ("http://www.flickr.com/services/rest/", FALSE);
  call = rest_proxy_new_call (proxy);
  rest_proxy_call_add_params (call,
                              "method", "flickr.test.echo",
                              "api_key", "",
                              "format", "xml",
                              NULL);
  rest_proxy_call_run (call, NULL, NULL); /* obviously can do async instead */
  payload = rest_proxy_call_get_payload (call);
  len = rest_proxy_call_get_payload_length (call);

Easy, huh? Anyway, enough rambling for today’s blog post, next week i’ll talk about the really interesting stuff we’re (Ross and I) are working on to make parsing XML fun (yes, really, honestly, fun.)

Oh and and the source code can be found in git and it’s licensed under LGPLv2.1, etc etc. (Yes, we have too many libraries, when mature perhaps we can move this into libsoup.)

And in completely unrelated news thanks to everyone involved in the organisation of GUADEC: Good work guys!

A little background on the idea of a Patchsquad: Primarily the idea is to reduce the workload of maintainers by commenting, not reviewing, patches that are waiting in Bugzilla. This may include testing, checking for obvious issues and gentle pestering of maintainers. Lucas held a BOF last year to introduce the idea that was well attended and a lot said but interest seems to have twindled. Myself and Diego want to try reinvigorate the idea!

Update: Whoops! Looks like we haven’t got that slot afterall. If you’re interested in the Patchsquad pleas some along and speak to either Diego or myself.

Direct listen again link. Playing in the browser is all garbled :-/