Note: After editing this wiki page, please track your changes.
I have turned Chat Room over to the original developer. I have committed a Drupal 7 Chat module, but have not had time to work on it for a while. Specifically, user status tracking is incomplete. Here are the plans for the currently dormant Chat project:
Goals
- Follow Drupal best practice, including that all pages be fully functional without JavaScript. This was the biggest challenge. While JavaScript is used to automatically update the chat interface, those who do not have JavaScript enabled can participate by manually updating the chat.
- Have no default dependencies beyond Drupal itself.
- Offer a BOSH override for Drupal’s built-in AJAX. AJAX requires repeatedly polling the site for updates, and does not allow connections to be shared. BOSH delays the server response until data is available.
- Provide a default backend for message exchange, but allow users to replace it with others.
Entities
A chat service hosted completely within a Drupal site would consist of interactions between the following entities. Some or all of them would be mapped to equivalent third-party objects or swapped for other components to work with other chat services.
- Chat message
- The basic unit of a chat. Contains all the fields for a single message. No revisions, and no URL. Each message belongs to a chat buffer.
- Chat buffer
- A chat buffer controls how messages are stored and retrieved. Each buffer has members who read from it, post to it, or both. The buffer keeps track of unread messages for each reader. Messages may be cleared when
- the buffer is deleted,
- all readers have read the messages, or
- the number of messages exceeds the buffer size setting.
- Chat member
- Any kind of entity may join a chat buffer. Members may be given permission to read, write, add members, remove members, or change buffer settings. Members may have a status of invited, active, away, invisible, or idle.
- Chat owner
- An owner can be any kind of entity. A chat buffer owned by a node becomes a channel. The owner controls message retention, membership, and permissions for a chat buffer.
Server-side message processing
Ultimately, the front-end should allow clients to handle message processing in a peer-to-peer fashion. This will improve performance and reduce the load on the server. However, in the first phase, all message processing will be handled by the server. This is the most compatible solution and allows us to support many protocols using built-in APIs.
Receiving a message will trigger an event on the server. Protocol plugins may define actions to take on the event. The built-in plugin will store the message as a message entity owned by a chat buffer and wait for readers to retrieve it. The chat buffer may keep messages
- in a database table,
- in a cache,
- in a file, or
- in shared memory.
The default storage method should be the one that is most reliable and best performing. For the first phase, this will probably be either a database table or a cache entry.
User interface
The default user interface will be a Drupal form that is updated by pressing a refresh button. Clients that support JavaScript can refresh the form automatically, and instead of retrieving the entire form, retrieve just unread messages. Even clients that do not support JavaScript may be able to refresh automatically using the same mechanism as the Batch API, if Drupal can cache forms built from GET requests.
The message submission form will be an entity form with a formatted text field. Text formats can be created to allow chat-specific formatting.
Default views will be provided to find and display chats.