Module Merger

Submitted by sun on Sun, 2007-02-11 15:53

I just recognized that there are three modules besides phpfreechat that claim to provide chatting features for a Drupal site. After a quick look at Buddy Chat, Chat Box and Chat Room I wasn't able to understand the differences between those modules. Furthermore, all of them are maintained by Darren Oh and the project description of Buddy Chat links to a forum discussion that outlines similiarities between Chat Box and - even more confusing - another module named Chat which seems to be available in CVS for Drupal 4.7 only.

So there seem to be at least four chat modules for Drupal, which is quite frustrating. WTF?! I thought by reading the development roadmap wiki page posted in this group - it seems to deal with a new way of on-site chatting by using comments for chats. But no word about merging all these modules to one.

Since I'm in the development of a new site I could think of helping out on a module merger with coding and/or testing. But since there apparently is no information about which module of those is the leading one and will be developed further I even can't find a starting point for any evaluations.

I would like to move this discussion into focus and start (or finalize?) a module merger with joined forces.

So I'm asking: Are there any plans to

outline the differences between all these modules on their project description pages
merge those differences into one module
upgrade that merged module to Drupal 5
re-think the development roadmap solely based on that merged module?

Groups:

Chat

Here's the differences

Darren Oh - Mon, 2007-02-12 14:51

The reason I maintain three chat projects is that I want to merge at least Chat Box and Chat Room. Buddy Chat may be too different to keep in the same module. Here is the current status of all the Drupal chat projects:

phpfreechat is a Drupal front-end to the phpfreechat program and requires phpfreechat to be installed.
Chat Box is obsolete. It reloads the page on each update instead of using AJAX. It does have two nice features: invitations and pop-up windows. Chat Box provides one chat for the whole site.
Buddy Chat provides private chats between users.
Chat Room provides group chats.

Chat Room and Buddy Chat are the only projects that I intend to continue developing. I plan to work on Chat Room first.

The feature requests for Chat Room have mostly been for functionality already present in the comment and forum modules. As I started to work on modified versions of those modules, I realized that we could save a lot of code duplication and probably improve performance by using the existing modules with a new JavaScript interface. This would also achieve compliance with the Drupal principle that pages should be able to display without JavaScript.

My current thinking is that each node should have a link that opens a pop-up window where users can view and send new comments in real time. I'm working on this as I have time. I would be grateful for any assistance you can offer.

Chat block

dwees - Mon, 2007-02-19 06:49

I created chat block for my site because I wanted a chat room that was by default 'on', that all of my authorized users could join, and was displayed on any pages I chose. The difference between my module and Chatroom is that I have one site-wide chat, and it is displayed as a block.

I also wrote my module because there are fewer Drupal 5 compatible chat modules, and I had tried to upgrade a couple of them myself to no success and decided it might be easier to write my own.

However, I can definitely see how this is, at least partially, a duplication of effort, and am certainly willing to join forces with another developer to merge our modules, removing mine from the projects list in the process.

Current features that my module has are:

Displayed as a block.
Updates via Ajax but degrades gracefully if Javascript is not present.
Admin can choose whether or not they see this block.
Includes a chat log page (which has a pagered view of all of the messages for the chat) which permissions to view can be configured.
Includes 2 levels of additional permissions, 'View chats' and 'Join chats'. Users who have the first can only see the chats going on, users who have both permissions can see and respond in the chat interface.
Smiley/URL replacement support is included, with a help page to show what text leads to what image/link.

I'd like to see whatever module ends up being chosen at the end to include these features.

Dave

Move discussion to issue

sun - Mon, 2007-02-19 15:35

I'd like to propose to move the module merger discussion related to chatblock on to this issue so it can be tracked by other users and more importantly, users who are evaluating which chat module to use (not everyone is hanging around here).

Daniel F. Kudwien
unleashed mind

I really like the idea of a

zirafa - Mon, 2007-02-19 11:21

I really like the idea of a chat just being an AJAX interface for comment submissions for a node. It opens up a lot of doors. Does it make sense to limit the number of comments stored at once, though? I would imagine a chatlog that is 1000+ messages long ends up being wasteful. Maybe the chat room module would only keep the last 50 or so messages and delete the rest of the comments. This could be configurable.

Will the interface rely on the 4.7 chatroom javascript, or is the plan to re-write with jquery?

What is the best way to help? I'm interested in seeing this happen.

zirafa

As far as I can tell: - Chat

Owen Barton - Mon, 2007-02-12 16:02

As far as I can tell:
- Chat Box is somewhat depreciated in favor of Chat Room
- Buddy Chat and 'Chat' is for person-to-person IM (AIM/ICQ etc) - rather than a 'room'

I think the only real overlap is between Chat Room and phpFreeChat. We discussed this previously and came to the conclusion that there was space for 2 modules here:

Chat Room being an easy to install, native Drupal chat room and phpFreeChat being a slightly harder to install (because of the 3rd party script download), but many-featured option.

I don't think Chat Room is going to be coming close to the feature set of phpFreeChat for a long while - but it is still a good option for sites that don't need or want all of phpFreeChats features.

To further complicate matters

Darren Oh - Sun, 2007-02-18 18:12

David Wees just added a chat block module. I guess my call for interested developers to collaborate is being ignored.

yes, I just recognized that,

sun - Sun, 2007-02-18 22:30

yes, I just recognized that, too.
But this seems to be an organizational problem with D.org. I don't know how this could be done properly, but any developer should be urged to look for similar existing projects in front of developing and introducing new ones.

Daniel F. Kudwien
unleashed mind

Plans for developing a chat module.

dwees - Thu, 2007-03-08 12:23

So we should start a list of features that we feel are necessary for a chat module, and try to serve up all of the most important of those features. Maybe develop a suite of modules that rely on a similar API?

I suppose one important step is outlining the flow of a chat module, and designing ways to make it less reliant on Javascript, which I've successfully done for my module (but I'm having problems getting the Javascript to work on everyone's website so I need to do a bit of a rewrite of the code - when I have time).

When I designed my chatblock module, I did so initially so that I could see if I had the coding expertise required to do such a project, and if I understood the flow of the connection between the client side Javascript and the PHP based server side script well enough to handle a somewhat complex task.

Anyway, here was the flow I used.

I basically created a MENU_CALLBACK that is called no matter what the operation I'm trying to do.

First the callback checks to see if the message has been sent back with AJAX by checking to see if some additional information has been added to the form (in this case, a random token). If this is set, it just updates the database and doesn't output anything at all.
If there is a $_POST['op'] (in which case I know the message has been sent without Javascript) it uses the information in the variable to update the chatblock messages database, then sends back the form.
No $_POST at all, and it just sends back the form.

Inside the chatblock form, there is an iframe where the source of the iframe is a MENU_CALLBACK. So the logic that controls the input of the form and the appearance of the form is then separated from the logic that controls the output of the form (which is presented as the chat window).

On each page load the Iframe is automatically updated from the database. Part of the information that is sent on a page load is the message id of the last message on the page.
If javascript is enabled, then depending on the settings in the admin/settings page, it is updated again every 5-10 seconds. However, the javascript reads the div that contains the hidden message id, and sends back that information to the server, which then only gets the messages that have a message id HIGHER than that (so in other words, messages the current user hasn't read yet), and these are appended to the end of the iframe content.

I think is pretty similar to what the flow should be for any chat module, but maybe some cleverer ways of sending the information to and from the server can be arranged?

Feature List Started

Darren Oh - Tue, 2007-03-27 21:07

I've started a list of features at the Chat Road Map. Don't be afraid to modify it. I hope to use the document as comments in the code of the module we produce.

Chat Room implements a couple of tricks to make updates more efficient:

Updates are handled by a call to chatroomread.php rather than a menu callback. This avoids the need to do a full bootstrap of Drupal on each update.
An empty file is created for each chat. Whenever something is modified, the modification time is updated on the file. Update requests are aborted if the modification time has not changed.