Note: After editing this wiki page, please track your changes.
Now that there is serious interest in contributing to this effort, it’s time to produce a unified road map for all chat projects. Chat Box has been retired. Chat Room is to be succeeded by a chat API which Chatblock, Buddy Chat, and other modules can use. Here are the plans:
Plan for Stable Chat Room Branches
- #195558 Needs maintainer.
Plan for Chat Room HEAD
HEAD will contain the code for the next Drupal 5 version until we create a DRUPAL-5--2 branch, at which point we will begin porting to Drupal 6. The stable Drupal 5 branch can be ported to Drupal 6 in parallel if a maintainer is found.
The code will be split into channel owner, engine, and interface components which can be used together or separately. This will allow developers to write replacements for each component and allow channels to be used by multiple sites:
The channel owner can be a node, CCK field, user profile, block, page, etc. The channel owner performs the following functions:
- Issue commands to channel engine.
- Store settings for users.
- Respond to system messages from channel.
- Configure channel interface.
- Provide channel listing.
- Provide interface to channel history.
- Create channel
- Open channel (allow chatting in channel)
- Close channel (stop chatting, but keep history)
- Remove channel
- View channel history
- Search channel history
- Clear channel history
- Add user
- Remove user
- Rename user
- Change visibility (show or hide user)
- Change status
- Set user timeout (how often users must update when there is no activity in channel)
- Set user permissions
- Promote user to
- Channel ID
- Drupal ID
- Session ID
- Promote (whether or not user is a channel owner)
- Join channel
- Change name
- Change visibility
- Change status
- Promote self to
When the channel engine receives the following commands from a user who has permission to issue them, it will pass them to the channel owner:
- Rename user
- Change user status
- Change user permissions
- Promote user
The channel engine should not rename a user unless channel owner approves the new name.
The channel owner can respond by sending a message to all users or specific users and by saving settings for later use.
The channel owner configures the channel interface. The channel owner can provide a configuration URL to allow interfaces from external sites to request configuration.
The channel owner can provide a means of finding the channel. The listing can be created with taxonomy like forums, or with a view, or with a node containing a multi-channel CCK field.
The channel owner can provide an interface to view, search, and clear channel history. The channel owner can also force channel history to be cleared automatically.
The channel engine processes commands and update requests from the channel owner and users.
- Authenticate user.
- Determine whether the request contains a command.
- If there is no command, check for recent activity.
- If there is no recent activity and timeout period has not passed, do nothing. If there is recent activity or the timeout period has passed, send all messages since last update request and save user's update time. Also send updated user list. Remove users who have failed to update within a short period after most recent activity or timeout period.
- Determine whether user has permission to issue command.
- If user does not have permission, do nothing. Otherwise, process command.
- Apply input format to messages.
- Share permission changes and promotions with channel owner.
- Request approval for name changes.
The channel interface sends update requests and provides users with a means of sending commands to the channel engine. The interface may be loaded and configured by the channel owner or may request configuration through a URL. The interface should be able to work with any engine if loaded with the correct settings:
- Update URL
- Command URL
- User settings
Depending on the capabilities of the engine and the permissions of the user, the following panels should be available:
- Enter text
- Select input format
- Select whether message is public or private
- Submit commands to engine
- Request updates
- Display messages
- Message alerts
- Display status of users
- View details of users
- Select users to receive private messages
- Submit commands
- Remove users
- Set visibility
- Set status
- Promote users
- Change user permissions
- User alerts
The following tasks need to be completed to create the new version of Chat Room:
- #195316 Create a channel engine module.
- #195318 Create an interface module.
- #195317 Create a channel owner node type module.
The node type module will replace the current Chat Room module, which contains the channel engine and interface in addition to the node type. It will provide an upgrade for users of the current version. The upgrade should automatically enable the channel engine and interface modules.
Most of the code for these modules already exists in Chat Room. However, it can be greatly simplified in the new version. Code can also be borrowed from the following projects:
- Chat Box, the original Drupal chat module, which used a pop-up window and included its own invitation feature (more on invitations later).
- phpfreechat, demonstrates a division between the channel engine and the channel content type.
- Drupal ajaxIM, fork of ajaxIM to Drupal. Depends on a server process and doesn't use jQuery, but the developers are working on a Drupal channel engine.
Messages themselves should go through a server-side filtering process, implemented with hook_chatroom_alter (or the like). This is where smilies and the like could be introduced.
The Buddy Chat module uses a pop-up window for chats. It also creates channels for each member of a user's buddy list. Once Buddy Chat is ported to Drupal 5 (#116994), it can be used to send invitations to join Chat Room channels. In the future, Buddy Chat should be modified:
- #170404 The Buddylist dependency should be removed.
- #97454 Invitations should be sent in pop-up windows.
- It should be made independent of the interface.
- It should use the channels engine to create channels.
- #97459 Users should be able to combine channels.
- As an alternative to creating channels for each user, one channel could be used for all users. A chat would consist of all messages which are addressed to a particular set of users. Users could be in more than one chat. For every chat, a separate interface (pop-up window or tab) would be created.
- Real-time comments (in development)
- Streaming chat (not started)
It is possible replace channels with comments using zirafa’s comment engine.
Instead of channels, the site maintains an open HTTP connection to each user. History is saved on the users’ machines.
Channels must have at least one owner, but may have more than one. Owners may own more than one channel. This means that owners can add users from one channel to another channel, and can pass messages from one channel to another. An interface may request command, update, and configure URLs from all channel owners, so if one URL fails another can be used.
This will provide robust protection against channel failure on any single site. Since users can be promoted to channel owners, users who allow incoming HTTP requests on their machines can run their own channel engines and provide access to the channel for other users. The first channel owner has all permissions and cannot be demoted, so if other owners abuse the channel, the channel owner can demote them or remove them (which would also remove access to and from their channels).
Peer-to-peer chat has the potential to drastically reduce the load on a single site hosting an active channel, since update requests would be distributed among multiple peers. The chat interface could rotate update requests between the available URLs, sending more frequent requests to those which perform better.
In cases where the interface is rotating update requests between multiple URLs, methods of avoiding duplicate responses would need to be developed.