Jump to content

Chat Application


robertf

Recommended Posts

I am going to develop a live help chat system with the basic features being similar to www.providesupport.com and http://www.liveperson.com/

 

I am unsure how to structure the application. I want to have a web based chat script for an end user to interact with our support staff who will use an admin console to manage different chats. I am planning on using a mix of PHP/JavaScript/AJAX to implement the end users chat and Java to build the admin panel. There will also be a MySQL database to store settings/chats etc.

 

The key features I want to include are:

- Support for multiple concurrent chats

- Multiple operators

- Transfer chats between operators

- ?User is typing? notifications

- Logging of each chat into database

- Online/Offline mode

 

I have come up with three possible approaches for the basic architecture of the system, particularly in how the chat element works. I am unsure which approach is best and was hoping you could point me in the correct direct and point out any advantages/disadvantages I have missed.

 

Approach 1 ? Static HTML files for chat

The PHP user chat box writes to and reads from a HTML file which contains the chat. Then reload this file every few seconds to ensure updates are shown. The Java admin end would also do something similar.

 

Advantages:

- Messages are logged throughout.

- Operators could manage different chats by loading different HTML files

- Different operators can load the same chat, allowing transfer of users

 

Disadvantages

- User is typing notifications would need some separate method

 

Approach 2  - MySQL database to store chats

The chat would be written to a MySQL database as each new message is typed. The admin and user end would then check for updates in the database every few seconds and reload the chat windows if it has occurred.

 

Advantages:

- Messages are logged throughout as each message is stored in DB.

- Operators could manage different chats through different SQL queries

- Different operators can load the same chat, allowing transfer of users

 

Disadvantages:

- User is typing notifications would need some separate method

- The database would get extremely large

- Constantly querying the database could have high server load and become slow with a large table

 

Approach 3 ? Direct socket connections

The PHP web end has a socket connection directly to the Java admin client that they are talking to. All the chat data goes through this, then when the chat is finished, it is written to the database to be stored.

 

Advantages:

- Would be quick as each party would know when a new message is received

- ?User is typing? messages could be sent over the socket connection

- Data is logged

 

Disadvantages:

- Socket connection could be lost, therefore ending the chat.

- Not sure how transfer of chat between operators would work

 

Summary

So, to summarize, which method would be best? Is there a better methods that I have not thought of? I have looked at HTML5 web sockets but I need a good browser compatibility.

 

In addition to this, how would I achieve having an online/offline indicator depending on whether admin users are logged in?

 

I am after a more generic overview as opposed to code etc?

 

Thanks for your help.

n

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.