Our WebChat workflow will be simple. If you try to access the system and aren't logged in it will route you to a login page (login.php). If you're not registered, you can go to the registration page (register.php), and from there log in. Once you're logged in, you are routed to the chat page (chat.php) and can engage in chat with other logged-in users: you can add a comment or delete your own comments. From there you can log out (logout.php). This workflow is summarized in Figure 1.

Figure 2.1. Figure 1: WebChat workflow

Let's think a little bit about how we're going to store our user information. As mentioned previously, there are no SQL style schemas in Couchbase, only keys and values. In addition, we can't enumerate a list of keys in the Couchbase bucket we're using. This means we have to know what we're looking for before we look; we can't select * from TABLE as we would using an SQL query. Also, even assuming we've only got one application using the given bucket, care must be taken in key naming conventions so that collisions don't occur with keys of different types.

For our keys, we'll prefix each key first with the application name, then the key type, for example a user named jsmith will get a user key in Couchbase of chat::user::jsmith, where the value associated with that key will contain the account information. We're prefacing the user key with the application name in case we later choose to share this bucket with another application; if all applications follow this convention we're creating a namespace for each application and we can be avoid key collisions between apps.

For the user comments we'll keep a single key that lists the maximum comment number so far achieved, and the comments themselves will have keys containing their comment number, for example, chat::COMMENT#23

This is another method of determining the keys for values we may want to retrieve, somewhat different from that of the user list discussed above.

Though we won't be implementing an administration function for managing users in this example application, we want to design our data model to support that possibility. This means that it should be possible to enumerate all users. To allow this, for each user we add, we'll append the username to a string held in the key chat::userlist. We'll be using the API append() method to that this. append() is functionally equivalent to doing a get() on the key, appending the new user to the returned text, and storing it again. The append() method requires less code and is also atomic, while a get, modify, and update sequence would not be.

The value held by a given key is of a default maximum size of 1 megabyte, though it can be increased with server side configuration. This should be kept in mind if you are, for example, doing many appends in long running or large-scale applications that are likely to exceed this limit.