If my brief article about the Chandler Repository caught your interest, you might want to check out Andi’s blog, in which he discusses some of the design and implementation issues.
Accounts of software design from the time of implementation are incredibly valuable. Maybe someday we’ll have a search tool that lets you enter your implementation ideas and gives you back the accounts of people who have tried them before.
January, 2007
...now browsing by month
Quick addendum about the Chandler Repository
Wednesday, January 31st, 2007The Chandler Repository
Tuesday, January 30th, 2007I spent a few hours yesterday in the company of Andi Vajda, lead developer of the data repository component of the Open Source Applications Foundation’s Chandler project. We talked about the technical details of the repository.
The Chandler repository is an object database with some interesting design features:
- All links between objects are bidirectional. Andi’s main motivation for this choice was to be able to guarantee to clients that references aren’t dangling without having to implement a garbage collector.
- All objects have universally unique identifiers (UUIDs) to make equality testing trivial.
- Repositories are versioned. Aside from the usual rollback capabilities this enables, client code can inspect a particular object as it was in any extant version.
- In addition to a conventional notion of class inheritance, the Chandler repository supports a notion of “cloud inheritence” for merging data schemas when copying objects from one database to another.
The repository layer is cleanly separated from the layer of Chandler that knows the semantics of calendar items, tasks, and so forth. That layer is responsible for mapping its items to repository items. Interchange of personal information is carried out at this higher layer, not by the repository. There’s an interesting bit of Python metaprogramming by Philip Eby that hides some of the mapping complexity from the application-level programmer.
I’m going to have a look at the source to see how this works. There are popular application-building tools that carry out object/relational mappings (moving between the objects that are convenient to use in code and the representations that are convenient in the usual relational database), but this is the first time I’ve come face-to-face with an object/object mapping tool. I’ll report back when I’m better informed.
[Thanks to Andi for fact-checking this post!]
Scott Rosenberg’s Dreaming in Code [book pointer]
Tuesday, January 30th, 2007Scott Rosenberg’s Dreaming in Code is the best journalistic portrayal of software development that I’ve ever read.
The romantic cliché of the lone introverted genius shaping masterpieces through many midnights of unfathomable incantations is mercifully absent. Rosenberg follows the Open Source Applications Foundation’s Chandler project through several years of development, from initial impetus to its milestone 0.6 release. We see the process as it actually is: as a highly social undertaking in which people pass through the project, and the project passes through people’s lives. The developers have families, pets, outside interests; they also have passions (often conflicting) about technology and the process of creation.
Dreaming in Code is much more than a simple chronicle: Rosenberg delves deeply into the history of software development and the frustration it causes for its participants and customers as the results never seem to improve even as the underlying hardware undergoes the most rapid progress of any technology ever.
Issues of data representation, storage, and synchronization are front and center in Dreaming in Code, all carefully explained by the author in terms that make sense to the non-practitioner while remaining recognizable to us professionals (he’s really, really good at this).
I might give this book to my mom to read.
[Disclosure: I've known Andi Vajda, one of the developers portrayed in the book, for about twenty years, and count him as a friend.]