Apparently this is a very popular page and I have been neglecting it for a while. My goal is to finish it this weekend, but I like to drink, so I'm not going to promise anything.
Before I start, go Download Firefox 2 and Firebug. They will change your life.
Let's start by recapping what we did in the AJAX Chat Tutorial. Simple stuff. It had a send message function and a JavaScript function that polled the server at regular intervals.
What's our next step? Create a login obviously. Do we want to get all mixed up in the details of an AJAX login model? That's really a discussion for another tutorial, but since I'm *drinking let's touch on it.
When you use AJAX you need to remember to not break the web or try and reinvent it, You use AJAX to enhance it. A typical login model is fine. However, there are some pain points such as submitting your registration only to find out that your “user name” is already taken. How frustrating.
Never fear! We can use AJAX to tell a user as soon as they leave the text box that the “unique identifier” they have chose is already taken and they need to enter something a little more clever.
Anyway, while I'm on the subject, if Ubuntu and Mozilla were publicly held companies, that's where all my money would be invested right now.
As I sit out here in the Colorado sun, I realize how great life really is. Software development may be the greatest job since the invention of the porn star.
I'm currently logged into my server via. RDC complete with a collection of over 100 GB of songs. If I ran out of music to listen to, I could easily log into my work server that has 300+ GB of music.
Back to the AJAX IM. Before you start to develop AJAX applications, you really need to understand the medium that is HTTP / HTML / JavaScript / XML or JSON.
HTTP is a stateless environment, and before you start developing for the web, you really need to understand what that means. Stateless (in my mind) means each HTTP request is exactly the same as another HTTP request regardless of when where or how it was made. There is no mechanism to relate HTTP requests in the HTTP protocol.
This introduces quite a few problems while at the same time makes for a simple, straight-forward environment to work in.
So what is the messenger above and beyond the AJAX Chat Application? Well, other than login, we need code to check intermittently to see if there is any new messages waiting. This is where the AJAX nay-sayers start complaining about bandwidth, server cycles, etc. The fact is hardware and bandwidth are dirt cheap and if that's what's stopping you from creating this system, you have bigger problems than CPU cycles. Fact.
AJAX basically takes up zero bandwidth, even in the most extreme cases. The modern Internet environment is setup to handle videos, complicated Flash, even very large fat clients. 10K worth the data isn't going to “Clog the Pipes” at all.
The biggest issue we need to deal with is query processing time. That can easily be cured with intermediate tables and indexes. Worst case scenario, we need to throw developer hours at it. This is after a $5K investment in hardware, because let's face it, developer hours are expensive and hardware gets cheaper every day. So no bitching elitists.
I quick deviation of subject. I was told last night that Amazon.com hasn't turned a profit, and their pyrmid scam was more profitable. That sort of statement needs to be on the Daily WTF?
I'm really getting off (<insert B&B statement here) subject. So how will an AJAX Instant messenger work? When a user enters our site, we will create a session (defeating the stateless environment0 and regularly poll the server for new messages.
If there is a new message that the user hasn't recived yet, we will pop up a chat window. This might be better in a div or something else considering popus are basically eliminated (thank the Internet gods).
Before I start, go Download Firefox 2 and Firebug. They will change your life.
Let's start by recapping what we did in the AJAX Chat Tutorial. Simple stuff. It had a send message function and a JavaScript function that polled the server at regular intervals.
What's our next step? Create a login obviously. Do we want to get all mixed up in the details of an AJAX login model? That's really a discussion for another tutorial, but since I'm *drinking let's touch on it.
When you use AJAX you need to remember to not break the web or try and reinvent it, You use AJAX to enhance it. A typical login model is fine. However, there are some pain points such as submitting your registration only to find out that your “user name” is already taken. How frustrating.
Never fear! We can use AJAX to tell a user as soon as they leave the text box that the “unique identifier” they have chose is already taken and they need to enter something a little more clever.
Anyway, while I'm on the subject, if Ubuntu and Mozilla were publicly held companies, that's where all my money would be invested right now.
As I sit out here in the Colorado sun, I realize how great life really is. Software development may be the greatest job since the invention of the porn star.
I'm currently logged into my server via. RDC complete with a collection of over 100 GB of songs. If I ran out of music to listen to, I could easily log into my work server that has 300+ GB of music.
Back to the AJAX IM. Before you start to develop AJAX applications, you really need to understand the medium that is HTTP / HTML / JavaScript / XML or JSON.
HTTP is a stateless environment, and before you start developing for the web, you really need to understand what that means. Stateless (in my mind) means each HTTP request is exactly the same as another HTTP request regardless of when where or how it was made. There is no mechanism to relate HTTP requests in the HTTP protocol.
This introduces quite a few problems while at the same time makes for a simple, straight-forward environment to work in.
So what is the messenger above and beyond the AJAX Chat Application? Well, other than login, we need code to check intermittently to see if there is any new messages waiting. This is where the AJAX nay-sayers start complaining about bandwidth, server cycles, etc. The fact is hardware and bandwidth are dirt cheap and if that's what's stopping you from creating this system, you have bigger problems than CPU cycles. Fact.
AJAX basically takes up zero bandwidth, even in the most extreme cases. The modern Internet environment is setup to handle videos, complicated Flash, even very large fat clients. 10K worth the data isn't going to “Clog the Pipes” at all.
The biggest issue we need to deal with is query processing time. That can easily be cured with intermediate tables and indexes. Worst case scenario, we need to throw developer hours at it. This is after a $5K investment in hardware, because let's face it, developer hours are expensive and hardware gets cheaper every day. So no bitching elitists.
I quick deviation of subject. I was told last night that Amazon.com hasn't turned a profit, and their pyrmid scam was more profitable. That sort of statement needs to be on the Daily WTF?
I'm really getting off (<insert B&B statement here) subject. So how will an AJAX Instant messenger work? When a user enters our site, we will create a session (defeating the stateless environment0 and regularly poll the server for new messages.
If there is a new message that the user hasn't recived yet, we will pop up a chat window. This might be better in a div or something else considering popus are basically eliminated (thank the Internet gods).
(Work In Progress)
AJAX Instant Messenger tutorial adds to the AJAX Web Chat tutorial to create a site-wide instant messaging service. This tutorial is considerably more advanced than the AJAX Web Chat due to the many complex PHP and database access requirements. If you are looking for a quick start to AJAX programming, I suggest you start with the AJAX Web Chat tutorial.
AJAX Instant Messenger tutorial adds to the AJAX Web Chat tutorial to create a site-wide instant messaging service. This tutorial is considerably more advanced than the AJAX Web Chat due to the many complex PHP and database access requirements. If you are looking for a quick start to AJAX programming, I suggest you start with the AJAX Web Chat tutorial.
Architecture Overview
Unlike the simple AJAX Web Chat example, this tutorial will require many additional pieces in order for just the basic functionality to work. From a general overview, we will need:
Once we have established the chat, then the IM chat window will behave much like the AJAX Web Chat example.
We will also code a component that we can use to check the current online users and send them an IM chat request.
Unlike the simple AJAX Web Chat example, this tutorial will require many additional pieces in order for just the basic functionality to work. From a general overview, we will need:
- An Instant Message Window (Based off the AJAX Web Chat example)
- A Login Page
- An IM checker component
- A current users component
- A send IM component
Once we have established the chat, then the IM chat window will behave much like the AJAX Web Chat example.
We will also code a component that we can use to check the current online users and send them an IM chat request.
The Database
In the AJAX Web Chat Tutorial we put together a pretty simple database that consisted of two tables. One for messages and one to hold the current chat sessions. We didn't even use the chat sessions table in the AJAX Web Chat tutorial since we only had functionality for one chat area. In part 2 (not yet published) we created a simple users table so that we could allow users to enter the chat room with a custom user name.
In the AJAX Instant Message tutorial, we will make use of the chat sessions table and even add some additional tables so that we can identify when we have a chat request pending. Our IM checker component will periodically check an invite table to see if anyone is wanting to chat with us.
The database will need to know the list of currently active users as well. In order to do this, we will set a last active field to the current time on every page request or sent chat message for each user. If the user's last active time is less than 4 minutes, then we will consider them online.
In the AJAX Web Chat Tutorial we put together a pretty simple database that consisted of two tables. One for messages and one to hold the current chat sessions. We didn't even use the chat sessions table in the AJAX Web Chat tutorial since we only had functionality for one chat area. In part 2 (not yet published) we created a simple users table so that we could allow users to enter the chat room with a custom user name.
In the AJAX Instant Message tutorial, we will make use of the chat sessions table and even add some additional tables so that we can identify when we have a chat request pending. Our IM checker component will periodically check an invite table to see if anyone is wanting to chat with us.
The database will need to know the list of currently active users as well. In order to do this, we will set a last active field to the current time on every page request or sent chat message for each user. If the user's last active time is less than 4 minutes, then we will consider them online.