germinal: idea: todo: closing a gap with dbus and python

There is an unnatural separation in many common computing environments between “web space” and “local space”. They are both equally foreign to users (meaning we aren’t evolutionarily equipped with tools for natively manipulating these spaces, and we aren’t indigenous to them), and so making a distinction between them doesn’t help us use them.

There are some fundamental types of data we do natively understand, such as knowledge about people, places, and times. Applications that facilitate manipulating these types easily are good ones, but good software is hard to find. Anyway, more and more of this data is being published on the web. Our local desktop apps should make use of it, when they can, since in many places web connectivity is rather ubiquitous.

There are many ways this information is published on the web, whether it’s XML, RDF, microformats (my favorite), iCal, cvs, et al… This creates quite a burden on application developers who aren’t interested in the particular ins and outs of parsing, even with shared libraries and common tools, and shouldn’t necessarily have to implement such base and vulgar features.

Instead, it’d be more efficient if there was a local daemon that was responsible for the tasks of synchronizing these fundamental types, and was accessible from different processes. By having a central code base responsible for these concerns, maintenance costs are reduced, decoupling is encouraged to even the language and process level (eg you don’t need a library written in the same language of your application), and application authors can concentrate more on creating nice user experiences. This inherently increases the monotony of the user experience, because the same implementation for the same task is used everywhere that task is implemented.

DBus provides a nice basal glue for the interprocess communications. Python allows for rapid prototypes to get started with the daemon, and excellent XML support. There are wonderful microformat and XML parsers available for python, so I think that makes it a natural choice.

This daemon could programmatically take requests from processes running on the local system for the kinds of fundamental data already mentioned. This daemon knows which service providers the user likes and uses, knows how to retrieve these resources from the web, and also provides an easy programmatic interface and data structures that abstract away the incompatibilities between different formats.

Imagine the resulting system: a set of software applications that always work the same way with the kind of data you’d like to manipulate. Wherever you go the data is with you, because it’s both on the web AND on your computer. The user might not even be aware of the difference. It works consistently, and the user doesn’t need to worry about what format something is in. It just works.

Advertisements

Post a Comment

Required fields are marked *
*
*

%d bloggers like this: