I did not really need persistence in Klatschbase, because I never restarted the Lisp image Klatschbase was running in since version 0.2. The only reason I used a different Lisp image in 0.2 than in 0.1 was due to the fact that I moved Klatschbase to another server. Being able to deploy a new version without stopping your application is really a nice feature of Common Lisp.

However, an unexpected reboot of my virtual root server made it clear, that persistence would be a nice thing to have. The machine was rebooted again a few days later. Hence, I decided to do it. It was on my list, anyway.

So I reevaluated the options. I keep on looking at CouchDB. There are two Common Lisp libraries for it. I also played on connecting to it with simple-http directly. This works good.

I also had a brief look at Elepahnt. There was not a lot to see the last time I checked it out, but now it seems to have some good documentation. It is definitely worth a shot if you have to persist something.

But in the end, I decided that my persistence needs are quite basic. I just want to store the clients and their options and the rooms that the server has. I ended up also storing the current messages in the system. Lisp already has a fairly simpl way to store such things: writing s-expressions with write and reading them with read.

I have to admit that the approach that I used does not scale to well, because the whole state is written every n seconds (or minutes). But this is OK in the given context. The plus side is that it gave me persistence with under 100 lines of code.

Another thing I fixed in this version are the parameter names of the generic functions. For some reason I always thought that the names of the generic function parameters must be the respective class. Which means I ended up with generic function definitions like these:

(defgeneric poll-msgs-wait (msg-store t t))

This, of course, is not the case. While in sbcl the above code compiles, other Common Lisp implementations choke on them. The following, more readable version, should work fine:

(defgeneric poll-msgs-wait (msg-store start-key timeout))

I just had a chat with a friend using my chat software klatschbase. A few good ideas came up how to improve it. Since I yet have to set up trac, I simply blog about it.

1. Some people were irritated because they saw nothing dirtectly after sending a message. Hence, a special entry for direct feedback was introduced. But this also irritates some people, because in rooms they see their message twice. So this should probably be improved (e.g., by making it configurable by the user).
2. If the interval between message pulls is long, the user has to wait quite some time until they see their just send message. A simple workaround would be to trigger a pull when a message has been send successfully.
3. Messages should have hooks for citation and linking. While direct copying is no problem, linking yields a lot of questions. I'll get to this later.
4. Different colors in the entries for different people that send the message would be very neat.
5. Timestamps for entries are missing.
6. The client still cannot create rooms (even though the protocol allows it).
7. It would be nice if clients could store options, e.g., the rooms they subscribed to.

I would really like to add some kind of persistence to chat rooms (and maybe also to the chat clients), meaning that the messages are stored somewhere. Right now, they are only kept in memory and only the last few are kept. The messages could be stored in CouchDB (or SimpleDB).

However, there are a lot of open questions. Should every chat room get its messages stored? Should they be visible from the outside world? Or should they only be visible from authorized users? It would probably be nice if this could be set per room, but who should be allowed to set this? Currently, rooms are not owned by anyone.

Regarding the storage of client options: They could either store it on the serverside (persistence on CouchDB?) or on the client side, using cookies. However, cookies have bad Karma.