Todos / Task-tracking: Generic API

7 July 2009 (Tuesday)

Was just talking to Garry idly about how we enjoyed both NoKahuna and Things and how annoying it was that there was no way of making them work together, and we started building a fantasy API – a generic Task-tracking API which all the task-tracking webservices (RTM, NoKahuna, BackPack, and Mingle, Trac, Mantis, Bugzilla…) might then implement, and all our favourite clients (like Things, Things.touch, but also OmniFocus and others) would also implement (or provide plugin architectures or (open)source-level  access to allow others to implement).

Wouldn’t it be nice?

Some more thoughts we had:

It would be easy for people working across multiple organisations (as so many do) to aggregate their todo lists (domestic, projectA, projectB) – and also to aggregate shared todo list (ProjectA official) with any personal or confidential note (ProjectA e.g. – “speak to X about problem with day rate”)

Provided that the API was rich enough, any two webservices that supported enough of the API would be able to migrate tasks between them – in other words you could transfer your data from one to the other. That would be a compelling demonstration of trust in their own quality (and a user-attractor, I would think).

The API would be likely to need to be able to move very quickly – as the definition of what an “adequate” or even “minimal” API is likely to be quite fluid.

The first API that would be specified and implemented would be a “capabilities” API – listing a list of capability ids, together with a list for each of versions (“ticking: v1, v2”, “basic-editing: v1”, “reordering: v1”, “categorizing: v2”)

But it would be possible for clients to work in a read-only fashion with “remote to-do lists” without even having the API: two possibilities suggest themselves:

  • RSS: You could specify one or more RSS 2.0 feed for any  category / project in your client (e.g. in Things a  “project” or an “area of responsibility”). Any RSS item (with a mandatory guid and remote address) that appears in the feed is a ‘new’ (according to the guid) task to be listed in the feed. Any time the guid disappears from the feed, the task is marked as ticked, and if the guid reappears in the feed it is re-marked as unticked. Of course this means your task-list webservice provider has to support an RSS feed for your project…
  • Plain old HTML: If your task-list webservice provider doesn’t support RSS, then of course the client could support a url and look for relevant links – the relevant links could be identified by some geeky means such as looking for a specific pattern of url (e.g. for a particular nokahuna that might be %r{http://nokahuna.com/projects/1324/tasks/[0-9]+} using ruby’s RE syntax)
  • In both cases, the display of the task could show that it is remote and (most likely) uneditable – to make the change, you could visit the remote url.

Garry and I would like to start working on API spec together (with a reference implementation) and implement a test plugin starting with minimal RSS/PO-HTML support , but not sure how to get clients (like Things’ manufacturers Cultured Code) interested… any suggestions?

Advertisements

One Response to “Todos / Task-tracking: Generic API”

  1. Duff OMelia Says:

    I’m wondering if it might be useful to take an approach similar to active merchant ( http://www.activemerchant.org/ ). Create an API that lets you plug in different tools.


Comments are closed.

%d bloggers like this: