After my first article in CFDJ (Vol. 2, issue 8) - "Live Monitoring of User Sessions" - I had some new ideas about using the session-tracking framework to implement a sample instant messaging application.

By using the information of who is currently online with open sessions, I can provide users with an instant messaging system that enables them to send small text messages to each other while browsing the site. This would be a nice feature for community-based sites; for example, a site that offers books can enhance browsing with the add-on feature of instant messaging, which enables clients to assign themselves nicknames and send small instant messages to each other to discuss certain books. Sounds good, I thought, and implemented a prototype based on the live session monitor from my previous article.

How It Looks
As you can see from Figures 1 and 2, the screen is divided into a mainframe in which customers can browse the site (I use simple sample documents here), a lower frame in which the current list of logged-in users is visible (and autorefreshed twice every minute), and a text field to send an instant message to the users you've checked. This kind of implementation is just a sample I created for demonstration purposes. While browsing the site's content, users can send off instant messages (see Figures 2 and 3) that are delivered as popup boxes. Once delivered, the receiver can click Cancel to close the message or OK to reply to the sender (see Figure 4).

Since popup messages might be annoying to those users who logged in but didn't want to receive them, the implementation could easily be changed to present them as plain text in the lower frame. When implementing these features, clearly state to users that when they log in the instant messaging app, they may receive instant messages.

This article presents the implementation of the idea as well as the technical details behind it. When implementing this in the real world, other criteria should also be considered, such as providing users with the ability to pause instant messaging (temporarily going off the list) and to decide whether they'd like to receive the messages as popup boxes or plain text. As I only implemented this idea to demonstrate how to use the session-tracker framework, I'd greatly appreciate any feedback on design and implementation considerations from developers who bring it to reality.

How It Works
Let's look at how it was created. We have eight files; however, at least two shouldn't arouse any interest (Listings 1 and 2, index.cfm and welcome.cfm, respectively) because they only start the frameset and present some dummy data to browse.

The files login.cfm. (see Listing 3) and especially makeLogin.cfm (see Listing 4) let users set their nicknames, then insert the mappings of their Internet protocol (IP) addresses to these nicknames into the application-scoped nickname structure. This structure is necessary because it references all users by their names, not only their IPs. It's indexed by the IP address with the user's nickname as the value. Note: This could also have been coded using cookies to reference each user's nickname, but I used a server-side structure to keep things simple.

ListUsers.cfm (see Listing 5) is similar to the session report in my previous session-tracker article. It just loops over the session-tracker structure and lists all online users (with their nicknames derived from the nickname structure) along with a checkbox to check the message recipients. Beneath that listing, a text box is shown with a submit button that enables users to send off their messages. Using the checkboxes to check the receivers lets the user send an instant message to multiple recipients.

The really interesting stuff happens in the CF-specific files, Application.cfm (see Listing 6) and OnRequestEnd.cfm (see Listing 7); these are executed by the ColdFusion server before and after any request. Each logged-in user is stored in the application-scoped session-tracker structure with his or her IP address and the current timestamp to check for timed-out users. (See my previous article for more details.) OnRequestEnd.cfm is especially interesting since it also checks the application-scoped message queue at the end of each request for messages for the current user. If any messages are found in the current user's queue, they're displayed with the ability to send a direct reply. This message queue consists of a simple application-scoped structure that's indexed by users' IP addresses. This structure holds a small array that acts as the user's queue for each user (Figure 5 shows the architecture). By looping over that array, all message packages for the current user are extracted and displayed. A message package consists of a mini-structure that holds the sender's name and IP address (to reply), as well as the message text itself.

The interesting thing about displaying the messages may be the direct-reply feature, which is realized client-sided using JavaScript. The delivered message is shown as a confirm box in which the user can click OK or Cancel.

// Present message doReply = confirm("Message from #tmpPackage["from"]#:\n\n#tmpPackage["text"]#\n\n- Reply?");

Using this information, the script determines whether to ask the user for a replytext (using a JavaScript prompt box).

if (doReply) { // Prompt for reply message = prompt("Your reply to #tmpPackage["from"]#:",""); if ((message != "") && (message != null)) { // Send reply message parent.frames.frameBottom.location.href="sendMessage.cfm?message="+escape(message)+"&users=#URLEncodedFormat(tmpPackage["sender"])#"; }

If the user wishes to reply to a message and enters a short reply text, it's sent off unseen by invoking the sendMessage.cfm template in the lower frame (using JavaScript) with masked URL parameters that contain the message and its receiver.

SendMessage.cfm (see Listing 8) "sends" the message that's either submitted by the form in listUsers.cfm or handed over as URL parameters by the direct reply feature:

<cfparam name="URL.from" default=#tmpNickname#> <cfparam name="URL.sender" default=#CGI.REMOTE_ADDR#> <cfparam name="URL.message" default=""> <cfparam name="URL.users" default=""> <cfparam name="FORM.from" default=#URL.from#> <cfparam name="FORM.sender" default=#URL.sender#> <cfparam name="FORM.message" default=#URL.message#> <cfparam name="FORM.users" default=#URL.users#>

With these statements, the sendMail.cfm template can use FORM.parameters as well as URL.parameters to send off messages. As you may have already guessed, messages are simply sent in sendMessage.cfm by appending the message details (sender and text) as a message package at the receiver's queue using ArrayAppend(). Remember that this application-scoped queue is checked for new messages in OnRequestEnd.cfm.

Final Thoughts
This article demonstrates how to use the session tracker in real-life implementations and discusses some of the interesting techniques behind it. As this article resulted from the idea of using the session tracker, I'd appreciate feedback on this topic. To fully understand this article, it's necessary to read my previous one about live monitoring user sessions. It can also be found online at http://www.sys-con.com/coldfusion/article.cfm?id=136.

Additional ideas regarding the session tracker include extending this instant-messaging system into a chat system that could easily be developed based upon the concepts in this article.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Source Code