To place a call you needed a telephone number, of course, just like you need today. Nothing has changed in that respect. I remember knowing most of my friends numbers by heart. Those I didn't know, I had in my little black book, or they were scribbled on a piece of paper somewhere. My friends had one telephone — the apparatus in their (parents') homes — and thus exactly one phone number.

Thirty years later the situation is quite different. Nobody I know has only one number. Everybody and his uncle has at least an additional mobile phone. And an office number. And perhaps a SIP number. And the greatest problem of all is that I cannot for the life of me remember any of these phone numbers any more, which is due mainly to the fact that numbers change when people change mobile operators (some don't care to retain their existing cell phone number), and numbers change when people relocate. (There are vanity numbers in Germany, but these are quite expensive.)

What has also changed, at least for me, is the little black book. Aside from the printout I keep in case of disaster, I store my phone numbers electronically. In Apple's Addressbook app which syncs over nicely to iPhones and devices which have iSync support.

And what about other phones in the house? If I look around me, I find we have quite a few phones in this household. One PBX with three DECT phones connected to it. An IP phone in my office. Two iPhones. One BlackBerry. (And an innumerable number of older mobile phones in boxes in the cellar, but those don't count because they aren't used any longer.) All these devices also have built-in directories: the DECT models have their own but they can list numbers on the PBX, though a bit cumbersome. The IP phone has a telephone book. And LDAP access. And XML.

If I weren't so stingy, I'd get a cell phone flat rate and just use that. But I am stingy so I tend to use a land line phone to call land lines, so I have to choose the outgoing phone. As such I need my directory on all phones I use.

I've solved the problem by throwing large amounts of software at the hardware. Basically it's a mixture of getting my Addressbook into LDAP (ABxLDAP), massaging that into my Fritz!Box, and sucking some of the directory entries out to create a directory for the IP phone. Does it work? Yes. Is it simple? No. Why is it such a mess? Because there are far too many standards: standards for directory systems (LDAP), standards for SIP phones (XCAP), standards for DECT phones, and so on, and so forth.

Who knows: some day I may revert to the little black book and …

the rotary dialer. On the iPhone.

Thanks, Martin, and thank you Samhain for lending me a copy of Beltane II. Oh, and thanks to iX' excellent layouter for putting my photo up there.

That is all fine and dandy, but I want to be able to populate that directory from existing an existing database, and I don't want to fumble with import stuff from the Web interface.

It turns out that is easier said than done, and it took a while to find out how to do that. I finally managed, thanks to work done by Christoph Linder on a Thunderbird add-on called Thunder!Box.

Thunder!Box allows transferring contacts from your Thunderbird-Addressbook to the phonebook of a connected AVM FRITZ!Box FON router and back. You may also use your address book to initiate calls.

A Fritz!Box has a very special authentication handshake, which makes the implementation rather secure, but tricky to access. (AVM have published a technical note on this, in German.)

Anyways, to cut a long story short, I've implemented what I call fritzuploader — a small command-line tool which uploads an XML file containing a telephone directory to overwrite that in the Fritz!Box' flash.

I've been using this quite a bit and haven't experienced any problems with it, but note it might quite well fry your Fritz!Box. Further note, that you should probably use this a bit sparingly, as the number of writes to flash memory is finite.

The Github repository for fritzuploader contains a sample phonebook.csv you can use as a starting point, the tiny csv2xml converter to create the phonebook.xml file which is then finally uploaded to the Fritz!Box with fritzuploader. At this point the current telephone directory on the Fritz!Box is overwritten, so you'll want to back that up first via the Web interface.

The resulting import looks like this:

I'd be interested to hear if you are successful with other AVM Fritz!Box models.

Let's first have a look at the final result. You can follow along by installing a version of couchapp and CouchDB of course. Then go to the program's Github repository, clone the app, push it into CouchDB and launch the URL:

git clone http://github.com/jpmens/scrumptious.git
cd scrumptious
couchapp push http://localhost:5984/scrumptious

By pointing your Web browser at the URL given you by couchapp, you'll be redirected to a show function, from which you drag the generated bookmarklet URL to your browser bar: (I have to "generate" the bookmarklet for you because it contains the URL to your CouchDB instance; the show function determines the full path and creates the bookmarklet containing that.)

Go ahead and drag the link into your bookmarks bar: mine is shown as the little recycle symbol. When you've done that, click on view all bookmarks, which will take you to the paginated list of the bookmarks stored in your CouchDB. (Yes, there are three there already.

Clicking on the greater symbol takes you to a page describing the bookmark. Click on the bookmark title to take you to the URL saved with the bookmark. Within the description page, click on the "delete bookmark" to kill the document.

When visiting a site you wish to bookmark, press on the bookmarklet you saved in your bookmark bar when on the page. The text you select on the page becomes the bookmark's description, and you'll be propted to enter a list of (white space or comma-separated) tags for the page.

The bookmark is saved into CouchDB with a shortish _id (swiped from Jan's io), whereupon you get a confirmation page. (I'd have liked to have the update handler return a 302 redirection to the browser, but that isn't possible with CouchDB 0.11.)

The resulting bookmark looks like this:

One URL you may like to see is produced by a couchapp list: /_design/app/_list/bookmarksfile/all produces a bookmarks.html file you can import into some Web browsers. Now that we've seen the app at work, let me discuss its innards a bit.

Standalone applications

Couchapps are standalone applications. They consist of JavaScript and JSON documents stored in a CouchDB design document:

As a proof of concept, look no further than CouchDB's built-in administrative interface. Futon, as it's called, is just a collection of HTML, CSS, and Javascript files, and it is a fully functional database browser and JSON document editor, as well as the runner for CouchDB's functional test suite. The test suite is written in Javascript and runs from the browser. What else could more strongly indicate that Ajax and CouchDB go hand in hand?

I find that there is little documentation about couchapps, which is fair enough if you believe in "read the source" strategies, so I've created this trivial couchapp, and I'm going to point out the things I find most interesting, or situations where I had a hard time understanding what happens in couchapps.

del.icio.us

Del.icio.us is a service which lets me submit, describe, and tag URLs I find interesting. I can share these with the rest of the world or mark URLs as being private. They have a sexy Web interface with which I can create and manage my bookmarks, and there exist dozens of bookmarklets and clients for managing them. They also have an API.

The del.icio.us API allows me to submit an authenticated HTTP GET request with URL-encoded parameters containing the data for the bookmark I want to add to my collection. As an example, I can point any HTTP client (e.g. my Web browser) at a URL like

https://api.del.icio.us/v1/posts/add?
  url=...&description=...&tags=....

and create a new bookmark.

I thought it would be trivial to implement the del.icio.us API on top of a CouchDB database, which would have had the great advantage that I could use any of the dozens of del.icio.us clients to drop bookmarks into my CouchDB. Unfortunately, the guys over at del.icio.us decided to implement a not-so-REST-y interface to their service; to add a new bookmark, del.icio.us uses an HTTP GET request instead of a POST or a PUT request.

Without some sort of middleware which converts a GET request to a POST, there is no way to add a document to a CouchDB database — it must be either a POST or a PUT request. I can call an update handler, but update handlers in CouchDB support POST and PUT only, and Jan Lehnardt quickly pointed out in no uncertain terms that I was barking up the wrong tree, trying to GET into an update handler. He was right in pointing out on #couchdb that I was trying to circumvent REST principles. (And I'm grateful to him for having put me right.)

So, in order to POST to a CouchDB, I had to create a browser bookmarklet which does a POST request. There is a huge amount of information on how to make a bookmarklet, but I finally swiped code from Smart Bookmarks and Bookmarklets, which provided just what I was looking for: one click and the JavaScript submits a POST request to my update handler.

Tools used

Editing JavaScript via the Futon interface is a no go; you'll go crazy attempting it. The only sane method is via the couchapp program which does a quite a bit of magic on the fly. What does couchapp actually do? Well, these are some of the things I've found so far.

• Couchapp provides helper macros for getting code into your show and list functions. If you look at the file list/ls.js, you'll see a JavaScript comment that looks like this:

  // !json templates.index
  

  That is parsed by the couchapp utility when you invoke a push and the content of the file templates/index.html is inserted into our ls.js JavaScript, much like an #include in C, for example. Go ahead and view the app design document with Futon. The file's content becomes a JSON object called templates with an name index and as value, the content of the file. Neat.

• A similar macro facility called !code inserts JavaScript code from the specified path, which is relative to the top-level couchapp directory. (See example in updates/post.js.) When couchapp is run, it replaces the line with the content of the JavaScript file.

• Files in the _attachments directory are dumped into your CouchDB database as attachments. You'll note I've stored the CSS for the HTML in such an attachment, for example.

• I can have couchapp add documents to the CouchDB database; see three examples in the _docs directory. (This is why you get three bookmarks in your database when you push my simple app into your CouchDB.)

• JavaScript files in the lib/ file-system hierarchy are added to the design document, from which you can load them by requiring them, as in var mustache = require("lib/mustache");. Omit the .js extension when doing so, or CouchDB complains about infinite recursion or something similar.

Couchapp contains a lot more magic: invoke `couchapp generate whatever` and explore the files created for you in the file system!

You'll note I make some use of mustache.js — an indespensible templating system which thankfully allows me to keep code and HTML separate from eachother. Jan recently wrote a bit more about mustache.js, and the project's README contains the rest of what you need to get started.

Import from del.icio.us

You can import your existing del.icio.us bookmarks rather easily by grabbing an XML stream containing your own bookmarks and dumping that into a file mine.xml:

curl -sf -u username:password -o mine.xml https://api.del.icio.us/v1/posts/all

Let's massage that XML with the following small program (`delicious2couchdb.pl`) by "translating" the XML entities to corresponding JSON objects ready for CouchDB:

#!/usr/bin/perl

use strict;
use XML::Simple;
use JSON;

my $json = new JSON;
my $ref = XMLin('mine.xml', ForceArray => 1);
my @docs;

foreach my $post (@{$ref->{post}}) {
	my $book = {
		type	=> 'bookmark',
		url	=> $post->{href},
		date	=> $post->{time},
		tags	=> [ split(/\s+/, $post->{tag}) ],
		title	=> $post->{description},
		description	=> $post->{extended},
		hash	=> $post->{hash},		# Keep for reference
		imported => JSON::true,
		};
	push(@docs, $book);

}

my $all = {
	docs => [ @docs ],
};
print $json->encode($all);

The format produced by delicious2couchdb.pl is ready to be POSTed into CouchDB's _bulk_docs API:

./delicious2couchdb.pl |
  curl -X POST http://localhost:5984/scrumptious/_bulk_docs -d@-

The funny-looking @- is for curl: data is read from the named file, and as the file is a single dash, curl reads the data from standard input.

Further reading

There is a lot more to discover here, and I'd like to point out some neat Couch Apps:

• Jan Lehnardt's io (mentioned above already) is a CouchDB-based URL shortener.
• J Chris A. created sofa, a CouchDB-based blog, which is what he uses.
• Taskr is a task-tracking app by J Chris A.
• More at CouchApp.org

The chapter on Standalone Applications in CouchDB: The Definitive Guide talks a bit about Couch Apps, and I don't want you to miss my CouchDB Reference Card

1. Update notifications powered by an external process, and
2. Change notifications using the changes API.

External process

CouchDB uses external processes which read an update notification on stdin whenever a database is modified. To configure one or more such processes, edit your CouchDB's local.ini to read

[update_notification]
jpnoti=/usr/bin/couchjp

This process receives a JSON string as a notification which includes the name of the database that was just modified.

For example, whenever my twitter database changes, the couchjp program receives the following line on stdin:

{"type":"updated","db":"twitter"}

Your program could then retrieve the database name and go and look for what has changed. Or for example, the program could automatically launch replication, if you don't want to use continuous_replication as exists in CouchDB 0.11.

Change notifications

CouchDB has the so-called _changes database-API which your application can use to get Comet-style notification of changes, be it by your application polling the database to query if anything has changed since a particular time or by CouchDB providing your application with a continuous stream of changes. I'm not going to delve into this API much, because it is very well documented in the book CouchDB: The Definitive Guide. In essence, you use an HTTP GET request to pull in a list of changed documents.

What I am going to dig into though, is how to tap that API with a JavaScript interface created by Mikeal Rogers on top of node.js. Now, if you are like I, when you hear JavaScript, you probably think of those pesky alert('hello'); or document.write('whatever'); on Web pages here and there. Well, times change: JavaScript has become a server-side language, and there is little it cannot do, as node.js very impressively demonstrates. (Disclaimer: I am neither a JavaScript nor a node.js specialist, so I may be doing something incorrectly here.)

Enter node.js.

Node.js

node.js is an evented I/O framework built by Ryan Dahl on Google's V8 JavaScript engine. It provides a very efficient system to create scalable and efficient applications without having to understand or use threading, processes, etc. In an event-based model you register what should happen, and node.js takes care of calling the callback function (you define) when the specific event happens. People who are used to programming JavaScript in a Web browser application (with, for example, jQuery), know this model well.

The event-based programming model is fundamental to JavaScript programming, and node.js leverages this model to programs that can handle massively concurrent events with little memory and processing power.

You'll have to install node.js, but doing so is easy. Once you have that running, come back and continue here.

node.couch.js

Mikeal Rogers created what he calls a generic change consumer that you can point at a running CouchDB instance. This change consumer, written in node.js periodically checks all CouchDB databases for existence of a changes field in the design documents of databases. If such a changes field is found, it must contain valid node.js code, which is pulled in by the consumer and executed on the machine running node.

What this means, is that once you have a consumer running, you can use Futon or CouchApp to create and modify code which is stored in your database design document, and that code is automatically read by the consumer and is triggerred by any PUT, POST or DELETE to documents in your database.

Prerequisites

To follow what I'm doing here, you'll need a few things:

1. A running instance of CouchDB of course.
2. A working node.js engine. Instructions for obtaining the source and building it are on the node.js site. (Google's V8 JavaScript engine is contained in node.js' source.)
3. A copy of node.couch.js. Actually, we need only the two files in changes/lib.
4. A CouchDB database you can play with, and a design document, named whatever you like.

You then launch node with the service.js script and point it to the URL of your CouchDB instance. It is important to note that node need not run on the same machine as your CouchDB instance: thanks to CouchDB's RESTful HTTP interface, it can obviously be queried from afar. Furthermore, all JavaScript and/or Node.js dependencies must be accessible on the machine running node (i.e. the client machine). I've wrapped the lot into a small executable I've called couchlisten.js:

#!/usr/bin/env node

var service = require('node.couch.js/changes/lib/service');
var couchdbUrl = 'http://192.168.1.20:5984';

service.start(couchdbUrl);

So, what happens when I launch that program? node is executed and loads the required modules. The principal module is service, which then

1. Reads a list of all databases at the specified URI.
2. For each of the design documents, service tries to load the JavaScript contained in each of the changes fields. If the JavaScript code in the changes field contains an error, node will bail out and stop.
3. That JavaScript code sets up listeners to wait for document updates to actually occur.
4. service.js sets up an event to rescan CouchDB databases and design documents every 60 seconds.

Let me create a first design document called _design/app which contains the following JavaScript in the changes field:

I'll now start node on another window, and keep an eye on that, while we continue working here.

I'm now going to add a document to my database.

$ curl -X PUT http://home:5984/db/jane -d '{"name":"Jane","type":"card","sn":"Jolie"}'
{"ok":true,"id":"jane","rev":"1-73ecb8a37d617c04e52c982cd4de5e11"}

At the same instant, our node listener picks up the change and executes our JavaScript program, so we see on node's console:

{"seq":2,"id":"jane","changes":[{"rev":"1-73ecb8a37d617c04e52c982cd4de5e11"}],"doc":{"_id":"jane","_rev":"1-73ecb8a37d617c04e52c982cd4de5e11","name":"Jane","type":"card","sn":"Jolie"}}
Hey: Jane

The first line with the JSON string is printed by the JSON.stringify() method — useful for visualizing what our JavaScript has to work with. The second line (Hey: Jane) is printed by the second sys.puts().

Instantaneously.

Shall I delete that document? Ok, here goes:

curl -X DELETE http://home:5984/db/jane?rev=1-73ecb8a37d617c04e52c982cd4de5e11
{"ok":true,"id":"jane","rev":"2-1a6dfcfc0899864047813a9e7ae38b1f"}

whereupon our node program displays

{"seq":3,"id":"jane","changes":[{"rev":"2-1a6dfcfc0899864047813a9e7ae38b1f"}],"deleted":true,"doc":{"_id":"jane","_rev":"2-1a6dfcfc0899864047813a9e7ae38b1f","_deleted":true}}

Take particular note of the _deleted field, which allows me to differenciate whether I'm handling a real update or whether I should perhaps ignore this update notification as it is a deletion.

So far we've managed to create a minuscule JavaScript program contained in a CouchDB design document which is read by our node.js instance and executed whenever a document is added to (or deleted from) our CouchDB database.

Taking this a step further, let's see if we can actually do something with the updates.

Urgent tweets

Suppose I have a database into which messages (i.e. documents) are posted that may have a particular priority. I want to ensure that documents tagged with an "urgent" priority are notified to my Twitter account as soon as they are added to CouchDB.

The changes script in the design document now contains this JavaScript code, which relies on twitscript (a node.js module) to do the actual tweeting. In order to avoid update notifications for design documents, I check whether the document's ID is one of those.

I don't have to restart couchlisten.js, as it will pick up the modified design document momentarily. Let me show you what the result looks like in the following screen cast, which consists of three windows:

1. The top window is where I'll be submitting requests to CouchDB, using resty.
2. The window in the center shows the output of our local node.js program, which I've called couchlisten.js.
3. In the bottom window, I have a small node.js program based on twitter-node. This program "follows" the Twitter user who is submitting the "urgent" Tweets.

And the result is quite pleasing:

And then?

CouchDB's changes API together with node.js and a bit of JavaScript open the potential to create exciting applications that react in real time to database modifications. I can use these update notifications for all sorts of interesting tasks:

• I can use these update notifications to tally how many updates to a database have occurred, and then, initiate a backup to a remote site. (One that doesn't have CouchDB — I'd otherwise use replication for that, wouldn't I? )
• If I use CouchDB as a writing platform, I can post via XML-RPC to my WordPress, Blogger, MT, etc. blog as soon as a document changes.
• If I think "DNS" database, with a solution like my CouchDB pipe back-end to PowerDNS, I can use an update notification to send an alert e-mail to the domain's hostmaster, so that (s)he can verify the zone.

There is a lot to learn here, and I've only just started. For example, there is the CommonJS initiative which wants to create standardized modules for use in JavaScript. The good news? CouchDB supports this as well. There's also a lot more (for me) to learn about node.js, including the dozens of modules for it; these include Web servers, frameworks, database interfaces, templating systems, parsers, etc.

1. Follow his instructions on getting the app with git, for which you'll need an installed couchapp program.
2. Continue reading. (Hint: this is much more sexy and more in line with showing off what CouchDB is capable of.)

What I'm going to show you here, is how to replicate the content of the progit database Jan created. The result will be a copy of the Pro Git book on your machine:

I'm assuming that you

• have a running copy of CouchDB on a machine. (On a Mac, I recommend Jan's one-click CouchDB package; download, double-click, relax. )
• your CouchDB is running on address 127.0.0.1 and port 5984 (the defaults).

Send off a replication command to your CouchDB to "pull" the content of the database.

curl -X POST http://127.0.0.1:5984/_replicate -d \
      '{"source":"http://progit.couchone.com/progit",\
        "target":"progit",\
        "create_target":true}'

This instructs your CouchDB to connect to the source URL and start replicating the progit database. Your CouchDB will create the target database, also called progit. (Note: the create_target option is new for CouchDB 0.11; if you have an older version omit the option and pre-create the database in Futon.)

This can take a bit of time. When replication finishes, you should see the results, which will look something like this (reformatted for clarity):

{
   "ok" : true,
   "history" : [
      {
         "docs_read" : 10,
         "session_id" : "9c6ec637a9686e3078de963fa6774c56",
         "recorded_seq" : 10,
         "end_last_seq" : 10,
         "doc_write_failures" : 0,
         "start_time" : "Tue, 04 May 2010 06:54:22 GMT",
         "start_last_seq" : 0,
         "end_time" : "Tue, 04 May 2010 07:04:50 GMT",
         "missing_checked" : 0,
         "docs_written" : 10,
         "missing_found" : 10
      }
   ],
   "session_id" : "9c6ec637a9686e3078de963fa6774c56",
   "source_last_seq" : 10
}

Now point your Web browser at your own CouchDB instance (which is probably running on 127.0.0.1), with a URL of

http://127.0.0.1:5984/progit/_design/chacon/_show/chapter/01-chapter1

which should get you a page that looks like what you saw above.

After browsing around a bit, I recommend you use Futon to access your CouchDB instance (http://127.0.0.1:5984/_utils/index.html) and look at what is there. Fascinating.

And, if you didn't feel like doing all that and simply want to see what it looked like, you can do so here.

As part of the firehose, there is an API called the Streaming API which allows anybody access to a fraction of the stream, so I tapped into that. (I jokingly said yesterday that I may be responsible for some of the fail whales of the day.)

The stream we mere mortals have access to provides me with about 50.000 statuses (tweets) per hour, which adds up after a day or two. Here is a shot of the statuses streaming past:

The individual tweets are provided in JSON format, which suits me well, and I'll turn the tap off in an hour a day or two.

Instead of very long curl command-lines, you'll typically use the GET, PUT, POST, DELETE commands — functions imported to your shell from Resty.

I've made a short screencast to demonstrate:

That last command I showed you might be Resty's best, so I'll give it to you again, so that it sinks in:

GET /jane | PUT -V

Highly recommended.

Go ahead and get The Antepenultimate CouchDB Reference Card. If you have suggestions on how to improve it, I'd by happy to hear in the comments.

Update 2010-04-22: added getting documents by keys, more map/reduce, a bit of CouchApp, and a section I call "More relaxation" with pointers to related tools.
Update 2010-04-24: small fixes, added links
Update 2010-04-26: added replication filters and URL rewriting.
Update 2010-04-29: tweaked attachments section, and added pudo.
Update 2010-05-11: added update handlers.

CouchDB documents can have any number of files attached to them, including their MIME type, and each of these documents contains a revision number which CouchDB uses to support multiversion concurrency control (MVCC).

CouchDB is accessed via HTTP only; there are no application-specific binary protocols used, making it an ideal system to be put behind load-balancers and proxies. As such, one of the tools of the trade with which to quickly access CouchDB is curl.

For example, in order to create a database in CouchDB and add the document shown above, I do the following:

H=http://127.0.0.1:5984/
curl -X PUT $H/demo
{"ok":true}

curl -X PUT $H/demo/1 -d "`cat /tmp/jane.json`"
{"ok":true,"id":"1","rev":"1-2867008f6fa2e8e834745efc4da65b01"}

The first curl invocation creates a database called demo, and the second creates a new document with a key 1 reading the content of the data from the specified JSON text. CouchDB responds with a JSON structure indicating errors or success.

CouchDB's Futon utility, also accessible from a Web browser, shows the result and lets me modify the document, attach a file, etc. (CouchDB's tagline, relax, is neatly carried on in the name futon.)

According to its author, CouchDB is largely inspired by the Lotus Notes back-end (i.e. Lotus Domino), and I see a number of parallels:

• CouchDB detects and flags document conflicts when a document is updated on more than one server. However, contrary to Notes, it cannot merge individual portions of a document — that is an exercise left to the application.
• CouchDB and Lotus Notes are predestined for offline use with subsequent replication when online.
• I can set up CouchDB on a number of nodes (systems) and have a single master replicate to any number of slave nodes (on demand or continuously), and I can have an application write to any number of those nodes, effectively creating a multi-master system, just as with Lotus Notes. (The Lotus Notes client's automatic failover to a different cluster node I would implement with a proxy, just as I'd have to do with a Notes Web application.) As with Lotus Domino, a cluster of CouchDB nodes need not be implemented on identical hardware or operating system — a great plus.
• CouchDB integrates a view model for aggregating and reporting on documents in a database. Views are built dynamically, and they are defined withing special design documents. This is quite similar to they way I view Notes views.

There are, however, a number of things that Lotus Notes includes out of the box, which CouchDB doesn't:

• Notes has a very high and very granular level of security. (Encrypted connections, encrypted databases, reader and author fields, etc.)
• Due to its "all-in-a-box" model, Lotus Notes integrates e-mail, calendaring and directory services, which CouchDB doesn't do, of course, as it is a database layer only.

Whether these are required in Web applications or not, is debatable.

CouchDB uses JavaScript as its internal language, although others are possible, where Lotus Notes uses @Formula, LotusScript, Java, and the C API.

Where CouchDB certainly excels compared to Lotus Notes/Domino is upon storing a large number of documents. I remember creating a Notes application some years ago (on 7.x), with a database containing a couple of hundred thousand small documents (about 200 — 400 bytes per document) and two or three views. Whenever that database was opened on a Notes client, the whole system (client and server) crawled. Now, this is a bit like comparing apples and pine trees, but a CouchDB database with ten times the number of documents in the same application doesn't make the server sweat.

CouchDB is supported by a large number of programming languages (including LotusScript). For PHP developers out there, IBM has nice document called CouchDB basics for PHP developers on offer.

If I work with Lotus Notes, is it useful to know (or even to migrate certain applications to) CouchDB? The answer is yes. There are some resemblances, which make my life easy in a transition phase. As an Open Source product, CouchDB has no licensing fees (and support is available from CouchIO — the makers of CouchDB). I get to use whichever programming language I desire, and I'm not restricted by the "IDE" that the Domino Designer is. Complete applications called CouchApps can be store in and served by CouchDB,

Damien Katz, the man who rewrote the Lotus Notes @Formula language, is the author of CouchDB. He gives an interview which is worthwhile listening to if you have the time. I recommend reading CouchDB: The Definitive Guide: I read it cover to cover and liked it, although you need a bit of imagination here and there. A good resource is also Matt Woodward's Massive CouchDB Brain Dump — a large collection of bullet points.