summaryrefslogtreecommitdiff
path: root/demo/prose
diff options
context:
space:
mode:
authorGravatar Adam Chlipala <adamc@hcoop.net>2009-04-05 11:48:55 -0400
committerGravatar Adam Chlipala <adamc@hcoop.net>2009-04-05 11:48:55 -0400
commitf6559c7555465c479d45529748deb8c15dfa346c (patch)
treeaffa61639daa2a14b7eb6c9f8bb56617fa62582c /demo/prose
parent37eeae6bc2503281d1b806c85aa0e70645fd9966 (diff)
Chat demo
Diffstat (limited to 'demo/prose')
-rw-r--r--demo/prose8
1 files changed, 8 insertions, 0 deletions
diff --git a/demo/prose b/demo/prose
index 45b7be00..d82ef7b5 100644
--- a/demo/prose
+++ b/demo/prose
@@ -256,3 +256,11 @@ roundTrip.urp
<p>The <tt>main</tt> function begins by retrieving the current client ID, allocating a new channel, and associating that channel with the current client in the database. Next, we allocate a buffer and return the page, which in its <tt>onload</tt> attribute starts two loops running in parallel. In contrast to in the last example, here we only use <tt>spawn</tt> with the call to the first loop, since every client-side event handler is implicitly started in a new thread.</tt>
<p>The first loop, <tt>receiver</tt>, repeatedly reads messages from the channel and writes them to the buffer. The second loop, <tt>sender</tt>, periodically sends messages to the channel. Client code can't send messages directly. Instead, we must use server-side functions to do the sending. Clients aren't trusted to pass channels to the server, so our server-side function <tt>writeBack</tt> instead keys off of the client ID, looking up the corresponding channel in the database.</p>
+
+chat.urp
+
+<p>This example provides a simple anonymous online chatting system, with multiple named channels.</p>
+
+<p>First, we build another useful component. Recall that each channel has an owning client, who has the exclusive ability to read messages sent to it. On top of that functionality, we can build a kind of broadcast channel that accepts multiple subscribers. The <tt>Broadcast</tt> module contains a functor with such an implementation. We instantiate the functor with the type of data we want to send over the channel. The functor output gives us an abstract type of "topics," which are subscribable IDs. When a client subscribes to a topic, it is handed a channel that it can use to read new messages on that topic. We also have an operation to count the number of subscribers to a topic. This number shouldn't be treated as too precise, since some clients that have surfed away from the application may still be considered subscribed until a timeout period elapses.</p>
+
+<p>The main <tt>Chat</tt> application includes some standard management of a table of named channels. All of the interesting client-server work is done with the <tt>recv</tt> function and with the functions provided by <tt>Broadcast</tt>.</p>