1.2 Building the Reminder Application

Let’s create a simple task list application in which anyone can create, read, and delete entries. To keep it simple, the user interface is irb.

Let’s define the Reminder class first. It has three methods: Add, delete, and to_a. Each item has a unique ID that’s used when deleting an item.

Let’s start the Reminder server via irb. We’ll run it in terminal 1.

Next we’ll use irb in terminal 2 as a client to this server.

Let’s start another client in a third terminal session and add and delete items.

The two clients are accessing the same shared data. This is because both terminals 2 and 3 share the same Reminder object, which exists on the server (terminal 1). The clients both have a remote reference to them (see Figure 3, ​Clients at terminals 2 and 3 operate the reminder at terminal 1​).

---

Figure 3. Clients at terminals 2 and 3 operate the reminder at terminal 1.

Next let’s check the object’s life span. Stop both client sessions by typing exit at the irb prompt. Then restart the client in terminal 2.

This is as we expected. The actual Reminder object exists on the server, so quitting and restarting the clients doesn’t have any impact on the data stored in it.

One of the benefits of using dRuby for your system is being able to share the state of a object across multiple processes. You could use dRuby as an alternative way to create persistence. For example, you could combine a short-running Common Gateway Interface (CGI) script and a long-running dRuby server when you write a web application.

To simplify the client operation, let’s write a ReminderCUI script. ReminderCUI is a character-based user interface that you can use via irb. This class has a list method to show all the items and a delete method to delete an item after confirmation.

Let’s start ReminderCUI at terminal 3 and do some experimentation (see Figure 4, ​The ReminderCUI at terminal 3 operates the reminder at terminal 1​).

---

Figure 4. The ReminderCUI at terminal 3 operates the reminder at terminal 1.

Using irb, you can create a multiclient program interface easily. We’ll add a web interface for this in Chapter 3, ​Integrating dRuby with eRuby​, so hold on!

In this section, we created a simple distributed application using dRuby. By now, you should have a pretty good idea of how dRuby works. But before we leave this introductory chapter, let’s dig a little deeper into the URIs we’ve been using to access our dRuby servers.

The Hostname and Port Number

The hostname and port number components of the URI are optional on the call to DRb.start_service.

If the hostname is specified, the connection is associated with that network interface. If omitted, TCPServer will automatically assign the hostname.

If the port name is 0, the first available port will be automatically assigned.

If nil is passed instead of a URI, then it acts as if both the hostname and the port number were omitted.

Here are some examples:

• ’druby://hostname:12345’: Both are specified.

• ’druby://:12345’: A hostname is omitted.

• ’druby://hostname:0’: A port number is omitted.

• ’druby://:0’: Both a hostname and a port number are omitted.

• nil: Both a hostname and a port number are omitted.

You can always find the host and port that were used by start_service by calling the method DRb.uri. Let’s try this in irb.

Now let’s try the “Hello, World” example without a URI. This time, use --prompt simple to simplify the irb prompt.

Start the server in terminal 1. Don’t pass a URI to it.

Now start the client in terminal 2, using the URI displayed by the server.

You should see “Hello, World.” pop up on terminal 1.

When we first tried the “Hello, World” app, we used localhost as the hostname, so we were able to run the clients on the same machine as the server. This time, we’ve used an externally accessible name, so you can try running a client on a separate machine that is networked with the server. Just specify the URI of the server, the same way you did when running the client locally.