So I am sipping some hot chocolate made from a recently purchased cream substitute by the name of Mimiccreme. Honestly, the stuff tastes good and better, it froths, unlike most non-dairy substitutes. Yet there is a hitch (there always is). As I was whisking away at my cream (mixed with water), I was staring blankly at the box and noticed that they have applied for a patent, which is indeed the case. Since their formula is made out of nuts, their motto is Not Crazy Just Nuts and if they are granted the patent (though I am confused as to what they are trying to patent) it will be Nuts and Crazy as well. update: Ettienne pointed us in the comments to the the patent application

Marxist photo of the day. Goes well with this older (but classic) video.

Our beloved dude is now the subject/object of academic study. I hope the essays are playful or else they just won t cut it.

Ok, since a few days there is always the same going on on one of the companies (hosted) servers: the RAID1 syncs in a loop because a medium error always happen during the rebuild progress:

May 5 21:55:28 spion29 kernel: [2339524.778339] md: md2: recovery done.
May 5 21:55:28 spion29 mdadm: RebuildFinished event detected on md device /dev/md2, component device mismatches found: 512
May 5 21:55:30 spion29 kernel: [2339526.287680] RAID1 conf printout:
May 5 21:55:30 spion29 kernel: [2339526.287702] --- wd:1 rd:2
May 5 21:55:30 spion29 kernel: [2339526.287712] disk 0, wo:1, o:1, dev:sda3
May 5 21:55:30 spion29 kernel: [2339526.287721] disk 1, wo:0, o:1, dev:sdb3
May 5 21:55:30 spion29 mdadm: RebuildStarted event detected on md device /dev/md2
May 5 21:55:30 spion29 kernel: [2339526.295476] RAID1 conf printout:
May 5 21:55:30 spion29 kernel: [2339526.295487] --- wd:1 rd:2
May 5 21:55:30 spion29 kernel: [2339526.295497] disk 1, wo:0, o:1, dev:sdb3
May 5 21:55:30 spion29 kernel: [2339526.295515] RAID1 conf printout:
May 5 21:55:30 spion29 kernel: [2339526.295523] --- wd:1 rd:2
May 5 21:55:30 spion29 kernel: [2339526.295531] disk 0, wo:1, o:1, dev:sda3
May 5 21:55:30 spion29 kernel: [2339526.295541] disk 1, wo:0, o:1, dev:sdb3
May 5 21:55:30 spion29 kernel: [2339526.295589] md: recovery of RAID array md2
May 5 21:55:30 spion29 kernel: [2339526.295598] md: minimum guaranteed speed: 1000 KB/sec/disk.
May 5 21:55:30 spion29 kernel: [2339526.295608] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
May 5 21:55:30 spion29 kernel: [2339526.295625] md: using 128k window, over a total of 390628416 blocks.
May 5 22:11:52 spion29 kernel: [2340506.396514] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
May 5 22:11:52 spion29 kernel: [2340506.396539] ata3.00: irq_stat 0x40000001
May 5 22:11:52 spion29 kernel: [2340506.396552] ata3.00: cmd 25/00:00:a2:20:ed/00:04:0e:00:00/e0 tag 0 dma 524288 in
May 5 22:11:52 spion29 kernel: [2340506.396553] res 51/40:00:c9:21:ed/18:00:0e:00:00/e0 Emask 0x9 (media error)
May 5 22:11:52 spion29 kernel: [2340506.396601] ata3.00: status: DRDY ERR
May 5 22:11:52 spion29 kernel: [2340506.396611] ata3.00: error: UNC
May 5 22:11:54 spion29 kernel: [2340507.733453] ata3.00: configured for UDMA/133
May 5 22:11:54 spion29 kernel: [2340507.733795] ata3: EH complete
May 5 22:11:54 spion29 kernel: [2340507.844814] sd 2:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
May 5 22:11:54 spion29 kernel: [2340507.851787] sd 2:0:0:0: [sdb] Write Protect is off
May 5 22:11:54 spion29 kernel: [2340507.851809] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
May 5 22:11:54 spion29 kernel: [2340507.852536] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Usually I would wait for the rebuild to be finished and asking the hosting provider to replace the second disk (sdb), but as the medium error causes just another rebuild process, this won't work for obvious reasons. So, the next plan is to fail the drive sdb and get a replacement disk then. Hopefully the first disk won't fail as well then... but well, Murphy, Backup, stuff... sigh

Like a poodle but chubbier, cuter, and probably smarter (not to mention tastier, if you are into the other white meat). I have always (this is serious) wanted a pet pig but they need to GE the thing to make it the size of a pug, then I would be all over it.

TIME: Monday, May 18, 7:00pm VENUE: Courant Institute
251 Mercer Street (Warren Weaver Hall)
Room 109 TITLE: The Struggle to Build a Digital Republic ABSTRACT: David Bollier will speak about the themes of his new book, Viral
Spiral: How the Commoners Built a Digital Republic of Their Own (New
Press). The book is the first comprehensive history of the free
culture movement and sharing economy that is empowering ordinary
people, disrupting markets and changing politics and culture. Bollier
will talk about the rise of free and open source software, Creative
Commons licenses, the new forms of non-market creativity (Wikipedia,
blogs, remix music, videos) as well as fascinating innovations in open
science, open education and open business models. More about the
book can be found at the website www.viralspiral.cc. More about
Bollier can be found at www.bollier.org. Bio
David Bollier is a leading American activist, author, blogger and
proponent of free culture on the Internet and the commons. He is an
editor of Onthecommons.org and Senior Fellow at the USC Annenberg
School for Communication. Bollier is also co-founder of Public
Knowledge, a Washington, D.C., organization that advocates for the
public s stake in the Internet and copyright law, and the author of
Silent Theft, Brand Name Bullies, and four other books. He lives in
Amherst, Massachusetts. VENUE: Courant Institute
251 Mercer Street (Warren Weaver Hall)
Room 109

So, recently our email overlords graciously provided means for us minions to help them in their toils and help clean up the spammish clutter in the mailing lists by helping report the spam. And the provided us with a dead simple means of reporting such spam to them. Now, us folks who knoweth that there is but one editor, the true editor, and its, err, proponent is RMS, use Gnus to follow the emacs mailing lists, either directly, or through gmane. There are plenty of examples out there showing how to automate reporting spam to gmane, so I won t bore y all with the details. Here I only show how one serves our list overlords, and smite the spam at the same time. Some background, from the Gnus info page. I ll try to keep it brief. There is far more functionality present if you read the documentation, but you can see that for yourself.

The Spam package provides Gnus with a centralized mechanism for detecting and filtering spam. It filters new mail, and processes messages according to whether they are spam or ham. There are two contact points between the Spam package and the rest of Gnus: checking new mail for spam, and leaving a group. Checking new mail for spam is done in one of two ways: while splitting incoming mail, or when you enter a group. Identifying spam messages is only half of the Spam package s job. The second half comes into play whenever you exit a group buffer. At this point, the Spam package does several things: it can add the contents of the ham or spam message to the dictionary of the filtering software, and it can report mail to various places using different protocols.

All this is very plugin and modular. The advantage is, that you can use various plugin front ends to identify spam and ham, or mark messages as you go through a group, and when you exit the group, spam is reported, ham and spam messages are copied to special destinations for future training of your filter. Since you inspect the marks put into the group buffer as you read the messages, there is a human involved in the processing, but as much as possible can be automated away. Do read the info page on the Spam package in Gnus, it is edifying. Anyway, here is a snippet from my etc/emacs/news/gnusrc.el file, which can help automate the tedium of reporting spam. This is perhaps more like how Gnus does things than having to press a special key for every spam, and which does nothing to help train your filter.

    1  (add-to-list
    2   'gnus-parameters
    3   '("^nnml:\\(debian-.*\\)$"
    4           (to-address . "\\1@lists.debian.org")
    5           (to-list . "\\1@lists.debian.org")
    6           (admin-address . "\\1-request@lists.debian.org")
    7           (spam-autodetect . t)
    8           (spam-autodetect-methods spam-use-gmane-xref spam-use-hashcash spam-use-BBDB)
    9           (spam-process '(spam spam-use-resend))
   10           (spam-report-resend-to . "report-listspam@lists.debian.org")
   11           (subscribed . t)
   12           (total-expire . t)
   13           ))

There is a lot of madness when it comes to psychiatry. One recent example of madness perhaps insanity is this faux peer review journal. At least there seems to be a growing counter-current in medicine that wants to sever the umbilical cord between doctors and drug companies as well as a vibrant grass roots move to embrace a different politics in and of madness.

This looks like a handy tool for wading through mailing lists. Has anyone used it with impressive/unimpressive results?

I subscribe to the iRobot mailing list for new products, discounts, etc. Today I got an email talking about great deals for mother's day. In case of you out there think this is a good idea, let's state this clearly:

This is not a good idea.

Giving someone a gift that reminds them of housework is a fast path to tears. Even if they're a geek. Just say no.

Wednesday 1st

At the G20 protests, Londoner Ian Tomlinson collapses and is attended to by the emergency services; Metropolitan Police claim "during this time a number of missiles - believed to be bottles - were being thrown at them". Tomlinson dies that evening.

Thursday 2nd

The Evening Standard reports that "police were bombarded with bricks, bottles and planks of wood" as they helped Tomlinson.

Saturday 4th

Postmortem of Tomlinson finds he died of a heart attack.

Monday 6th

The EC Data Retention Regulations 2009 comes into force requiring internet service providers to retain details of emails, internet phone calls and other web traffic.

Tuesday 7th

The Guardian publishes a video of a police officer assualting Tomlinson on 1st April.

Wednesday 8th

Twelve Pakistani students are arrested on suspicion of planning terror attacks over the Easter holiday weekend.

Thursday 9th

The Guardian publishes a second video of Tomlinson's assualt, contributing that no missiles were thrown.

Monday 13th

Police arrest 114 climate protestors on conspiracy to cause criminal damage at Nottingham power plant. [ref]

Tuesday 14th

A video of a seperate assualt at the G20 protests is published.

Thursday 16th

Police claim tourist's photography of transport-related buildings is "strictly forbidden" and demand the photos are deleted. [ref]

Friday 17th

A second postmortem of Iam Tomlinson finds the cause of death to be an abdominal haemorrhage. A policeman is interviewed under caution on suspicion of manslaughter. [ref]

Saturday 18th

The Times reveals MP Damian Green private emails were searched by the police using the keywords "Shami Chakrabarti" (director of Liberty) after his arrest last year.

Monday 20th

The Guardian reveals police intelligence was given to E.On before the Nottingham climate demonstration, including movements of protesters and their meetings.

Tuesday 21st

Another video of the Tomlinson assault is revealed showing his head hitting the pavement. The Independent Police Complaints Commission fails to obtain an injunction to prevent broadcast.

Wednesday 22nd

Nine Pakistani students arrested during anti-terror raids are released after 13 days without charge and are passed to UK Border Agency custody for deportation. [ref]

Monday 27th

Home Secretary Jacqui Smith announces that ISPs and telecoms companies will be asked to record usage "to track murderers and paedophiles" without a warrant. [ref]

Tuesday 28th

Emails are revealed of the Home Office asking Phorm, the behavioural targeted advertising service, whether they are falling outside the law. Home Office claim Phorm would be legal if consent is obtained and that "providers of goods and services need only ensure they are compliant with relevant legislation". [ref]

Wednesday 29th

The Guardian documents the friends of the 7/7 bombers were denied bail on secret evidence - "the appellant asked the judge the question: why are you sending me to prison? To which the judge replied: 'I cannot tell you that.'"

(The much-delayed part 2 in an ongoing series: shiny things in telepathy-glib) Over a year ago I explained my first major round of work on telepathy-glib, with which it could be used to implement D-Bus services. I started to write this post shortly after, but then got distracted by a bee or something; recent discussion about having a D-Bus binding in GLib has finally prompted me to finish it. The second major round of work on telepathy-glib dealt with implementing client code, and went sufficiently well that telepathy-qt4 (currently under development) uses essentially the same model. Again, while telepathy-glib is intended for Telepathy implementors, I think TpProxy's ideas are generically useful, particularly for "large" D-Bus APIs.

Some background: dbus-glib and libtelepathy

The life-cycle of a DBusGProxy (PD clipart credit: karderio and Andy)

The API provided by dbus-glib for client code is, er, rather less than ideal. The basic object is DBusGProxy, which has a few problems. There's one per interface, rather than one per object; this leads to a maze of twisty GObjects, all suspiciously similar. Our old client library, libtelepathy, got round this by subclassing DBusGProxy to make helper objects called TpChan, TpConn etc., which were simultaneously the proxy for the "main" interface (Channel, Connection etc.), and a factory for proxies for the other interfaces (like Channel.Type.Text and Channel.Interface.Password). This still wasn't ideal, but it was a start. If you use a DBusGProxy in any way after it has emitted the destroy signal, this is considered to be invalid use of the API, and dbus-glib asserts all over the place. We'd rather it didn't do that - remote objects becoming invalid is a fact of life, and if you don't immediately discard all your references to those objects, remote operations on them should just give you a runtime error. You have to be prepared to handle such runtime errors already, because any IPC call can fail at any time. The main API for calling methods uses varargs and is rather subtle. Notably, the calling convention for variant parameters (of D-Bus signature 'v') is not consistent with the calling convention for any other container. For any other container, for instance a GPtrArray *, you pass in a GPtrArray ** pointing to a GPtrArray * variable containing NULL; on success, a pointer to a new GPtrArray is written into that variable. For variant parameters, though, you must pass in a GValue * pointing to a zero-filled GValue, and the result will be written into that GValue. dbus-binding-tool generates thin wrappers around this method-calling API which provide type-safety, although they can't directly specify a non-default timeout. As for signals, before binding to a signal, you have to tell dbus-glib about its signature. This tells dbus-glib how it should push the signal arguments onto the C stack (in GObject terminology: how it should marshal them), to match the signature of the signal-handler function. The documentation claims that this isn't necessary for objects supporting the Introspect method, but that's untrue - on the other hand, if the documented behaviour actually happened, I would consider this to be a critical bug in dbus-glib, since it would enable remote objects to crash dbus-glib clients (by causing signal arguments to be pushed onto the stack in a way that does not match the signature of the signal handler). Of course, the signal-adding function takes varargs, and has to be called exactly once per signal per object. If you don't, dbus-glib asserts when you connect to the signal; if you call it twice, dbus-glib asserts anyway.

TpProxy TpProxy is a GObject subclass vaguely inspired by Python's dbus.proxy.ProxyObject. It isn't a subclass of DBusGProxy, which lets us encapsulate dbus-glib almost completely - in fact, all the references to DBusGProxy are in a separate header, proxy-subclass.h, only used by subclasses of TpProxy (as opposed to normal library API users). TpProxy instances are per-remote-object (per-object-path) like in dbus-python, rather than per-interface like in dbus-glib or QtDBus. As explained below, I believe that this is the most natural object mapping for D-Bus interfaces; in practice it tends to lead to clearer code for us, since one remote object often maps nicely to one UI element (of course, if your objects only have one interface, this approach is no better or worse than dbus-glib's). TpProxy provides support for the following common D-Bus things:

• Calling methods
• Connecting to signals
• Objects becoming invalid
• Objects with optional interfaces
• Extensibility

It doesn't currently provide any particular help with Properties - the Properties interface is just another interface as far as we're concerned. We find that, in practice, that's not a problem (even though we use D-Bus properties extensively). In telepathy-qt4 we basically reinvented TpProxy in C++, as Tp::DBusProxy. I've put in some comments below illustrating how the general ideas we used in TpProxy translate into a different object mapping.

Calling methods Method calls on TpProxy are done through auto-generated wrapper functions, much like DBusGProxy. These look something like this:

typedef void (*tp_cli_channel_callback_for_close) (TpChannel *proxy,
    /* any 'out' arguments would go here - Close() doesn't have any */
    const GError *error, gpointer user_data,
    GObject *weak_object);
TpProxyPendingCall *tp_cli_channel_call_close (TpChannel *proxy,
    gint timeout_ms,
    /* any 'in' arguments would go here - Close() doesn't have any */
    tp_cli_channel_callback_for_close callback,
    gpointer user_data,
    GDestroyNotify destroy,
    GObject *weak_object);

Methods for some interfaces, like DBus.Properties, are available on TpProxy itself; others, like Telepathy's Channel.anything, are only available on a particular subclass, like TpChannel. Things to note here:

• It's an asynchronous call with a callback. General design principle: "this is IPC, get over it". We don't try to hide the fact that IPC is taking place by doing pseudo-blocking calls.
• The timeout is explicit (although you can always pass -1 to let libdbus pick a "reasonable" default for you). This is because the remote service might not respond, and API users should be at least vaguely aware of this: "this is IPC, get over it".
• The callback isn't a GCallback; it has an explicit signature, for some semblance of type-safety (it's not much, but it's better than nothing).
• The callback takes a GError, because any IPC call can fail for any reason.
• A TpProxyPendingCall * is returned. This is a pointer to an object that only exists until just after the callback is called (so you can ignore it if you don't want it), with a method you can call to cancel the method call (with hindsight this is not ideal, and if I was writing this API now, I'd use gio's GCancellable). "Cancel" is perhaps slightly misleading: the method call still takes place (it was already in libdbus's outgoing queue) but the result gets ignored and the callback isn't called. This is mostly so you an object can forget all the calls it was busy making at the time that the results become irrelevant (e.g. the object is destroyed).
• There is an extra weak_object argument, which is weakly referenced and is passed to the callback: in practice, most users of telepathy-glib use this as well as or instead of user_data. If the weak_object runs out of references, the callback is automatically cancelled, which means that in practice, explicit cancellation is almost never needed.
• The generated code has as its first argument a suitable subclass of TpProxy, in this case TpChannel (we tell the code generator about subclasses).
• You can't see it in the API, but the TpProxy gains an extra ref while a method call is in progress, so you never have to worry about what happens if the proxy gets unreffed during a method call.
• There's an explicit destructor for the user_data, which is called even if you "cancel" the method call.

In telepathy-qt4, these methods are on small generated helper classes similar to dbus-python's dbus.Interface, one per interface (we provide accessors for them on the non-generated DBusProxy subclass). Instead of using callbacks, we return a temporary QObject per call, which emits a Qt signal on success or failure (that's how all async calls in QtDBus work).

Connecting to signals Similarly, signals have some generated functions:

typedef void (*tp_cli_channel_signal_callback_closed) (TpChannel *proxy,
    /* any arguments would go here - Closed doesn't have any */
    gpointer user_data, GObject *weak_object);
TpProxySignalConnection *tp_cli_channel_connect_to_closed (TpChannel *proxy,
    tp_cli_channel_signal_callback_closed callback,
    gpointer user_data,
    GDestroyNotify destroy,
    GObject *weak_object,
    GError **error);

API notes for these:

• The callback doesn't take a GError any more, because signals can't fail; the weak_object and the user_data are the same as for method calls
• This isn't actually a GObject signal at all: those aren't particularly typesafe, and lack namespacing. This might not be very binding-friendly, we haven't tried doing that yet... it might be worth introducing a signal with details, like in dbus-glib, for which these functions are "C bindings".
• The returned TpProxySignalConnection lets you disconnect from the signal, just like the TpProxyPendingCall above; it can safely be ignored
• Similarly, if the weak_object dies, then the signal automatically disconnects
• It is possible for connecting to a signal to fail: this happens if the proxy doesn't actually have the requested interface. If this happens, it's graceful, not a crash. In practice, the flow of code is almost always such that error can safely be NULL because the interfaces are already known.

In telepathy-qt4 the per-interface generated helper classes emit Qt signals. In many cases, we end up proxying these signals by responding to them in the hand-written Tp::DBusProxy subclass by emitting a different signal, in order to give them a nicer representation.

Becoming invalid This is IPC, and any error can happen to you at any time. We found that it was useful to have a general concept of "this object is no longer useful", so we introduced the concept of an object becoming invalidated. The invalidation reason is stored on the object as a GError. If this GError is NULL (as it is initially), then the object is still expected to be valid; if it's non-NULL, the remote object has vanished and the local proxy no longer works. There are several ways a TpProxy can become invalid:

• its bus name falls off the bus (the process exited or crashed)
• application-specific reasons (usually triggered by a D-Bus signal in a subclass, like the Telepathy Channel's Closed signal)
• the GObject gets disposed

Method calls on an invalidated object always fail, with the invalidation reason as the error. This means that calling a method on a TpProxy should never crash your process. The method's callback has to be prepared to handle an error in any case, because this is Sparta^WIPC, so there's no loss in giving it another error. Connecting to signals on an invalidated object always fails, and any existing signal connections are disconnected when it becomes invalidated. This means that if a new remote object appears, and it happens to have the same object path, bus name etc. as the old one, you won't get its signals. A TpProxy can either be bound to a unique bus name or a well-known bus name. In the equivalent code in telepathy-qt4, we call this "stateful" or "stateless" - these names don't capture the intention perfectly, but they're the best we could come up with. A proxy for a stateful API like Telepathy's Channel should always bind to a unique name - when the unique name falls off the bus, the TpProxy becomes invalidated automatically, representing the fact that the Channel you had no longer exists, and nothing can be a perfect replacement for it (the VoIP call has already been terminated, you've already left the chatroom, or whatever - if you make another Channel, that's e.g. a distinct VoIP call). A proxy for a stateless API like Telepathy's ConnectionManager, where an exiting process can disappear, be service-activated again, and still have exactly the same API, should bind to the well-known name. Proxies for well-known names aren't invalidated when the process exits. Qt doesn't have a natural equivalent for GError, so the invalidation reasons in telepathy-qt4 are just a pair of strings, the namespaced name and the message - basically a libdbus DBusError. The principle is the same, though.

Optional interfaces As mentioned above, TpProxy instances are per-remote-object (per-object-path) like in dbus-python, rather than per-interface like in dbus-glib or QtDBus. I believe that this is the most natural object mapping for the D-Bus object model, because the D-Bus interfaces on a remote object can behave like any of these:

• classes and subclasses (Telepathy.Channel.Type.Text is a Telepathy.Channel)
• shared interfaces (some Telepathy.Channel objects, of many Types, implement Telepathy.Channel.Interface.Group; any D-Bus object can implement DBus.Properties)
• optional features (some Telepathy.Channel.Type.Text objects implement Telepathy.Channel.Interface.ChatStates, some do not)
• discoverable extensions (some Telepathy.Channel.Type.Text objects implement Telepathy.Channel.Interface.Messages, which is more or less Text 2.0)

The way in which interfaces are discovered is also variable. The "classic" D-Bus way to discover interfaces would be to call Introspect. Telepathy services still support that style of introspection, but we don't use it for anything beyond d-feet:

• Introspect returns a blob of XML, which you have to parse into something useful; if it was in a D-Bus data structure, you'd already have some sensible data structure.
• Finding out more information about the supported interfaces than their names isn't very useful: in a static language like C you already need to know the methods, signals, properties and their signatures in order to write and compile your code, and in a dynamic language like Python consumers of Introspect end up being remotely crashable by services with unexpected method signatures (this is one of dbus-python's big mistakes in my opinion).
• If a method that you want to call turns out to be missing, the worst that can happen (in a competently written service) is that it fails with a D-Bus error - and you have to handle D-Bus errors anyway, because this is IPC and anything could fail.
• Static bindings like dbus-glib have poor support for removing interfaces for which C code exists at runtime, whereas Telepathy needs features like an IM connection that might or might not support avatars (we don't get to find out until we've successfully connected to the server).

Instead, our older interfaces have a method on the "base class" (Channel, Connection etc.) called GetInterfaces, which just returns an array of strings. Newer interfaces (like Account), and older interfaces that have been ported (like Channel), have a property called Interfaces which is, again, an array of strings - this lets us combine the download of the interfaces list with downloading other basic information in a GetAll call. To cater for all these ways to use interfaces, the TpProxy base class has very basic support for interface discovery - you can ask it whether it supports an interface, and you can tell it that it does, in fact, support an interface. Asking which interfaces are supported is directly useful for library users; it's also used as a check by the generated method-call and signal-connection stubs, which return a canned error (Telepathy.Error.NotImplemented in Telepathy's case) if the object isn't known to have the interface. Telling TpProxy that it does support an interface is intended for use by subclasses, and might have been protected if we were writing C++: what happens in practice is that a concrete subclass like TpChannel knows how to discover the fully supported interfaces for this particular object, does so, and calls methods on the TpProxy to tell it which interfaces can work.

Extensibility The API stubs used by TpProxy to call methods and bind to signals are generated from XML documents containing an augmented form of D-Bus introspection data. These XML documents contain various Telepathy-specific extensions, but none of the extensions are language-specific - telepathy-glib, telepathy-python and telepathy-qt4 all operate from exactly the same XML specification. telepathy-qt4's different object-mapping did require us to tighten up some rules that were previously only conventions, but even so, the format is the same. I think this is vitally important - it just doesn't scale to have one set of language-specific annotations in a D-Bus API for each language that will have bindings. One thing that we make heavy use of is what I call "Ugly_Case", which is camel-case with underscores at word boundaries. This gives us a simple, unambiguous and foolproof rule to use in code generators whenever we generate any of the popular conventions for identifiers:

• CamelCase: delete underscores
• javaCamelCase: force everything before the first underscore to lower case, then delete underscores
• lower_case: force everything to lower case, retain underscores
• UPPER_CASE: force everything to upper case, retain underscores

dbus-glib, by contrast, applies a complex and subtly buggy algorithm to the CamelCase D-Bus names, which results in our SendDTMF method being mapped into GLib as send_dt_mf, and requires that telepathy-glib's Python reimplementation of dbus-binding-tool uses a bug-for-bug compatible implementation (we ended up reimplementing dbus-binding-tool in order to generate the TpProxy-based bindings). Our code generation tools are still rather ad-hoc, because so is our spec format, but for draft interfaces it's possible to copy them into individual projects and use them to generate additional methods for TpProxy or any subclass. This is how we implement unfinished APIs like geolocation in Empathy, for instance. The Interfaces or GetInterfaces hook described above is entirely usable for these extension interfaces, and in fact that's how they're set up. In telepathy-qt4, the generated method stubs are genuine C++ methods, so we can't just append methods to an existing class: this is why we have one helper class per interface, so individual clients can generate a helper class for their particular version of an unfinished API, and instantiate an object of this class attached to a particular Tp::DBusProxy. When an interface becomes stable, it can be added to the set of interfaces for which code is generated in telepathy-glib or telepathy-qt4, at which point any client or service that was already using the final draft of that interface can easily be ported to the library version using sed (the API remains the same).

Becoming ready The concept of being "ready" does not directly exist in TpProxy, but is implemented in TpChannel, TpConnection and TpConnectionManager. The idea is that a freshly created proxy object isn't really fully usable yet - you have to connect to basic signals and recover the initial state of the remote object, as well as checking which extension interfaces are supported. In many well-designed D-Bus APIs you can do this initial setup with a few signal connections and a DBus.Properties.GetAll call. After doing that initial setup (which has to be done asynchronously, because it's IPC), the TpProxy subclass has a local cache of the remote object's state (not necessarily in the same format as the representation on the bus), which can be accessed synchronously at any time, and will be updated in response to change-notification signals. TpChannel and subclasses like it have explicit support for checking for readiness, and having a callback called when the object is ready or invalidated (whichever happens first). The "ready" property also supports the GObject notify signal. telepathy-qt4 took this concept and ran with it - there is library support for objects that can become ready, including a mixin. If I had as much time to work on telepathy-glib as I wish I had, this would be one of the first telepathy-qt4 features to be added to telepathy-glib.

Features becoming ready Going beyond that, in an extensible framework like Telepathy it's probable that not every client understands (or wants to understand) every feature of every object, so it's highly inefficient for every proxy object to subscribe to all the change notification signals and cache all the remote state on the off-chance that the library user wants them. In the API for TpContact (which is not actually a TpProxy for various reasons) we introduced the concept of optional features; telepathy-qt4 extended this idea throughout the library. The idea is that each library user knows which of the optional features are "interesting" to it, and makes a single asynchronous call (which expands into a series of D-Bus calls inside the library) to download the state for core functionality plus all of the selected features, and subscribe to change notification for all of those. This is another telepathy-qt4 thing that telepathy-glib still needs to catch up with; until someone works out how to make the clone() syscall apply to programmers, I fear all libraries are doomed to lag behind how their designers want them to look :-) (license: CC-BY-3.0 / LGPL-2.1+)

This Sunday in the Burg, NYC.

Anyone who knew me prior to 2000, knew me as a fanatic Ultimate Frisbee player. I was (mostly) all about chasing a plastic disc on lush green fields. Ultimate Frisbee, which took my attention and soul my first year of college, commanded my attention, time, and body for years. The New York Times just ran a nice short piece piece about Ultimate Frisbee, which apparently has skyrocketed in popularity since 2003. One section of the article caught my attention:

It may be a non-contact sport according to its rules, but Ultimate is hardly free of injuries. The quick cutting and sprinting have made anterior cruciate ligament tears among women players especially common. JOY CHEN, a 33-year-old software developer in Alameda, Calif., considers herself lucky that herniated disks, a rotator cuff tear and ankle sprains have been the extent of her Ultimate injuries. We hit each other and the ground pretty hard, said Ms. Chen, who discovered Ultimate in college after years as a soccer and tennis player. She played with Stanford University s Superfly, which went on a three-year run as undefeated women s national collegiate champions.

Injury goes with the sport as hand and glove and young players tend to wear these injuries as a badge of pride. As much as I adore the sport and there are days I get pretty bummed that I no longer play I think that the UPA and older players should seriously skool the younger generation on the danger of injuries. It is an extreme sport that requires extreme care. Tournaments are usually composed of 4-7 games over the course of 2 days. If that is not demanding enough, the body gets pretty intimate with the the ground while laying out and then there are there all those sprained ankles and broken bones and ligaments from collisions. Today I suffer from bouts of knarly neck pain, for example, which is due in part from playing without taking proper precautions. One of my best friends, who was a stellar player in college, also suffers from pretty devastating back pain. It is an extreme sport that requires extreme care. I say toss out the pride in pain/injuries and in place, instill a healthy sense of fear of the injuries so that people get proper long term and sustained care for their injuries so that they can keep on playing the world s best sport. PS For those that don t know, UF also revolves around an ethical philosophy Spirit of the Game, which unfortunately the article makes no mention of, despite its centrality to the sport.

Feel the fear and do it anyway

Do you use GPG or PGP to sign or encrypt your emails and/or files? This is a reminder to those who answered yes: make sure you have a revocation certificate, as well as backups of your private/public key pair, ideally in multiple safe locations. It s always a good idea to keep backups. But what is more important with GPG is the revocation certificate. That s your emergency brake. If someone ever gains control over your key, this is the only way for you to minimise (further) abuse of your key and your identity. However, even a revocation certificate won t be able to prevent all abuse, by nature of the design of the GPG Web of Trust. You also need to exercise utmost care in protecting your key and making sure third parties cannot gain control over it. Do not keep it on machines you don t trust, and make sure to use a safe, non-guessable passphrase! With GnuPG, generating a revocation certificate is as easy as this; replace $KEYID with your 8 or 16 digit hexadecimal key ID:

gpg --gen-revoke $KEYID > $KEYID.revoke.asc

and store it away. Do not import it until you need to revoke your key! In my case, the process was this; lines requiring my input are prefixed with an arrow ( ):

  sec  1024D/330C4A75 2001-06-20 Martin F. Krafft <mail@martin-krafft.net>
  Create a revocation certificate for this key? (y/N) y
  Please select the reason for the revocation:
    0 = No reason specified
    1 = Key has been compromised
    2 = Key is superseded
    3 = Key is no longer used
    Q = Cancel
  (Probably you want to select 1 here)
  Your decision? 1
  Enter an optional description; end it with an empty line:
  > 
  Reason for revocation: Key has been compromised
  (No description given)
  Is this okay? (y/N) y
  You need a passphrase to unlock the secret key for
  user: "Martin F. Krafft <mail@martin-krafft.net>"
  1024-bit DSA key, ID 330C4A75, created 2001-06-20
  ASCII armored output forced.
  Revocation certificate created.
  Please move it to a medium which you can hide away; if Mallory gets
  access to this certificate he can use it to make your key unusable.
  It is smart to print this certificate and store it away, just in case
  your media become unreadable.  But have some caution:  The print system of
  your machine might store the data and make it available to others!

I then printed the file, put it in the safe, stored it on a removable disk and hid it away. Even though I exercise great care over my key material, I can now sleep better at night, knowing that I can at least minimise any damage done by an attacker who compromises my key. Also, that way I can make sure to declare unused keys as such, since there is no other way to revoke a published key for which you ve lost the private key or forgotten its passphrase. I ve left such traces in my past and wish I had known what I was doing at the time: A8FA196E, C22D1C01, 1EF0975C. This is your chance to do it right. Make yourself a revocation certificate now (along with backups)! And always exercise care and keep your key secure. NP: Mono: One More Step and You Die

Today I found out that some of my students refer to me as Enid, a name which has rarely been used to call my attention but now circulates almost daily to my students whenever I post a message on Blackboard. It was a little mortifying to find out as I don t identify much with Enid, though it has always tagged quietly along with my other names. BB, which we use for readings, our discussion forum,and email messages, spits out my legal (tax) name, which bears the full Enid Gabriella Coleman. Although I have tried, somewhat persistently, I have failed to change it to the E. Gabriella Coleman that I would rather use. While I find it hard to embrace Enid as I just don t feel like an Enid, at least yet (and may break it out when I write fiction or when I turn 65), I have always liked having the name Enid in so far as it pays homage to my Aunt Enid whose life ended far too early, soon before I was born and from all accounts, she was one stellar woman. My parents chose to tack it on for commemorative purposes, intending to call me Gabriella after some Italian cabaret singer my mother loved. The plan, however, was immediately foiled by my older sister who apparently blurted out something like Biella when she saw the scraggly rat-like baby (as my mom used to describe me) that was christened her younger sister. Biella, like Gabriella, also has Italian roots: it is a beautiful town in Italty and a less than beautiful but so-ugly-it-is-kinda-cute Italian Pug. Perhaps the lesson in all of this is to tell students about my name and finally ditch BB, which is the software equivalent to Soviet style communist housing, and move over to another platform.

Today I found out that some of my students refer to me as Enid, a name which has rarely been used to call my attention but now circulates almost daily to my students whenever I post a message on Blackboard. It was a little mortifying to find out as I don t identify much with Enid, though it has always tagged quietly along with my other names. BB, which we use for readings, our discussion forum,and email messages, spits out my legal (tax) name, which bears the full Enid Gabriella Coleman. Although I have tried, somewhat persistently, I have failed to change it to the E. Gabriella Coleman that I would rather use. While I find it hard to embrace Enid as I just don t feel like an Enid, at least yet (and may break it out when I write fiction or when I turn 65), I have always liked having the name Enid in so far as it pays homage to my Aunt Enid whose life ended far too early, soon before I was born and from all accounts, she was one stellar woman. My parents chose to tack it on for commemorative purposes, intending to call me Gabriella after some Italian cabaret singer my mother loved. The plan, however, was immediately foiled by my older sister who apparently blurted out something like Biella when she saw the scraggly rat-like baby (as my mom used to describe me) that was christened her younger sister. Biella, like Gabriella, also has Italian roots: it is a beautiful town in Italty and a less than beautiful but so-ugly-it-is-kinda-cute Italian Pug. Perhaps the lesson in all of this is to tell students about my name and finally ditch BB, which is the software equivalent to Soviet style communist housing, and move over to another platform.

Last Thursday, I went to the Social Enterprise summit regional workshop that I mentioned. Apparently, SEC are hoping that ministers Mandelson, Purnell, Byrne and Blears will be at the summit, along with people from various famous co-ops. I took along some email feedback I received on supporting new blood in social enterprise about needing help to bridge the gaps (financial, social, training) between taking on new members and them being productive enough to break even . Happily, that was echoed and reinforced by other delegates - I shared a table with people from Trinity Community Arts, AvonCDA, Sofa Project, Somerset Co-operative Services and Community Action. Emboldened by that, I ranted about the Business Support Simplification Programme (which seems to mean that only BusinessLinkSW has any gov.uk money in our region and they re being really poor at co-op support) and I threw a couple of ideological-explosives into the consultation, suggesting that franchising has failed as a way of spreading social enterprise and we need to start offering General Public Licensing of our business models, because we re not franchising businesses and most of us don t want to be. I wonder if that idea will detonate somewhere helpful. The Social Enterprise Coalition officers had some details of the support programmes that are already announced. One of them is a golden hello where the enterprise gets money when a new person joins. It s run by jobcentreplus. So yesterday, when I was at a Business Link Real help for business event, I asked the jobcentreplus officers there about it: apparently it s useless to TTLLP because all our workers are partners and not employees. I was expecting more support for co-ops from a Labour+Co-op government, but it shouldn t've been a surprise after the budget. After that, I don t think it s worth posting details of the other SE assistance programmes mentioned: they ll probably turn out to be equally useless for co-ops and I don t want to waste your time. I ll rant about that and the BusinessLinkSW event another day or in another place. Ask me if you want details and I ll put them in a comment or email them. And in that spirit, it s back to programming for me!