AJAX chat using phpfreechat (clean code, active development, easily themable, with disk/ram based modes to minimize server distress). My module allows chat to be enabled/disabled per content type and node, gives full control of each phpfreechat parameter, and passes handling of refresh requests to a separate script to avoid Drupal bootstrap overhead.
Still got some final touches to do, but it's mostly done for 4.6. It could be upgraded to 4.7, but I doubt that is a full summers worth of work.
Possibly we could come up with some more features to be implemented - but it might be a little tough :-/
Drop me a line and we can talk about it (google page is going all '502 server error' on me).
What can I say - great minds think alike :) I just finished work on a fully fledged chat module for Drupal 4.6 when I saw your application.
Please take a look - http://drupal.org/node/62389 - the code is in Drupal cvs: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/phpfreechat/
My current list of todos is:
* Update for Drupal 4.7!
* Add chat blocks
* Fix debug setting (which currently breaks the chat)
* Look at integrating theming (map Drupal theme onto phpFreeChat theme)
* Wait for phpFreeChat 1.0 (with /kick etc) and integrate into the Drupal access rights system
This (I hope) provides a solid base to build on for AJAX chat in Drupal. It would be great (if you are interested) for you to build on this code (rather than start from scratch). If this is the case, then one question (probably for Robert) is this: some of the ideas you suggest would involve contributing to the phpFreeChat project as much as to the Drupal integration module. I am not sure if this is allowed by the SoC project or how other Drupal folks feel about this. The todo list above would also be a great start, but is probably not a summers worth of work :)
On the other hand, if you do want to start from scratch then I was wondering what client technology are you intending to use? You mention using HTTP-streaming - which implies Java or Flash (since Javascript cannot, I think, open raw http sockets). I have done a lot of research into potential chat clients (especially AJAX and Flash) and would be interested to know what ideas you had here, or if there are any projects you would be looking integrating. Building a fully featured chat client (on any platform) is a huge undertaking, and I have some concerns about the length of time that would take.
Anyway, it's great we are thinking along the same lines!
thanks for reaching out to this one. It's not really possible to work for two mentoring orgs, nor is it possible to have mentors from two orgs both coach 1 student. These ideas were tossed around a bit on the mailing lists, but I think Google would rather just keep it simple. Let us know what kind of response you get.
This is a little different from the situation discussed on the SoC list, as phpFreeChat is not actually a SoC mentor org. If Ralf was selected then, apart from the work upgrading the module to 4.7 and adding chat blocks a lot of the additional features/work would actually be on the phpFreeChat codebase. Now, Drupal would obviously benefit from this, as we get a tighter integrated and more fully featured chat client (and, of course we could also pull some people looking for a chat platform to the Drupal/phpFreeChat combo). I don't see any reason why both mentors could not be from Drupal, although obviously plenty of cooperation with the phpFreeChat folks would be needed too. From reading the Google docs, this seems OK (since we are basically using phpFreeChat as a library), but I don't know what other Drupal folks think about the idea of one of our students spending a bunch of time working on 'another project' :)
I can understand both sides here, and, while I would be delighted if Ralf's (and other mentors) focus went towards improving the phpfreechat module and phpFreeChat client I would not be offended if it was decided that we wanted to focus more on Drupal. There is also the objection to 3rd party integration (with while I agree in general) I think that phpFreeChat is worth integration - writing something this highly featured ourselves would be a lot of work.
Anyway, please let me know your thoughts!
I attach two replies from Ralf (over e-mail) below.
Thanks!
- Owen
Hi Owen,
On Sun, 2006-05-07 at 23:37 -0700, Owen Barton wrote:
What can I say - great minds think alike :) I just finished work on a
fully fledged chat module for Drupal 4.6 when I saw your application.
I wasn't aware of your module, but it looks really nice. Of course I am
always open to reuse a existing code base. At the moment, the plan is to
extend Chatbox. But your module seems to be another good alternative.
However, I received critical feedback about the usage of third party
software, so I would have to double check this.
One comment regarding the streaming. Technically speaking, it's not the
right term. I refer to a technique where you simply don't close the
http-connection, an effect you can observe when loading very slow
server-side processed pages. I have used this approach in my prior
project http://ralfchat.com. It doesn't use any other technology than
pure HTML/HTTP on the client side. Have a look at the demo to see it in
action.
Thanks for your feedback and looking forward to a fruitful
corporation ;-)
regards Ralf
Hi Owen,
On Mon, 2006-05-08 at 08:35 -0700, Owen Barton wrote:
While chatbox is ideal as an occasional, low-volume chat (like a
shoutbox), it didn't fulfill my requirements. One thing is that it is
page-refresh based, so only operates as a popup window or in an
iframe. It would also not easily cope with many chatters because of
both the heavy database hits (drupal bootstrap sql + chatbox sql * 200
users hitting every 5 seconds would not look good!) and becuase it is
bandwidth inefficient (the entire chat history is sent every refresh).
I looked at several flash and java clients, and found several good
ones, but these nearly all needed software/access to the server that
would rule them out for shared hosting environments. The subset of
these that used php sockets seemed at a very early stage of
development.
I agree on the heavy server load of chatbox and its unsuitability for a
large number of users. These are two of the main objectives I want to
address with my proposal. The refresh method should definitely be
complemented by the mentioned streaming output. I think an interesting
idea would be to replace the HTML refresh method by a slimmer AJAX-like
callback (which is still depending on a regular refresh). The
administrator and optionally the user would then have the choice between
both output modes, similar to the options ralfchat provides. Both
methods have their advantages and disadvantages. Streaming works without
any client-side technology, in particular without JavaScript, whereas
AJAX is more likely to work with firewalls or proxies.
I looked at a bunch of AJAX chat scripts, but phpFreeChat was the only
one that was both sensitive to server performance (chat data can even
be stored in RAM, for super quick access), bandwidth (data is only
transmitted once) and features (text formatting and smilies, no
iframes, with chat ops/voice on the way for 1.0).
Today was the first time I came across phpFreeChat. It looks promising
and I like its handling. I'll install a drupal 4.6 testbed now to try
you integration module!
Yes, we do try an avoid 3rd party software (especially in core), but
there are some applications where it does make sense (such as wysiwyg
editors) and I think the addition of a featurefull ajax chat is one of
these.
Yes, I agree. Especially if the integration is tight, but not bound to a
specific setup/version. If both Drupal and phpFreeChat can be maintained
and updated independently and both provide the needed plugin
functionality I don't see a reason to not take advantage of mature 3rd
party software.
That's an interesting technique (and one I haven't seen before!). I
guess the pros of this technique are CPU and bandwidth, but the con
would be memory (lots of apache threads!).
That summaries the differences pretty well. BTW, during research you
might encounter the synonymous terms pushlet or server push. The
tradeoff remains, but in my point of view, Apache should be able to
balance the load and minimise the overhead of its threads better than
any cgi/php application could do. A real performance comparison might be
helpful.
Anyway, I'll see what Robert thinks about the issue of contributions
to other projects (once the Drupal todos are done, the majority of
work on new features would actually be on the phpFreeChat codebase)
and get back to you. Feel free to get back to me with any further
ideas/discussions!
Thank you for your support! Please keep me updated about the status, I'm
always thankful for new ideas and suggestions.
Regarding your second email, of course you can quote these emails to the
mentor/drupal community.
The reason I'm so critical of Ralf's application is because it's written to integrate his self-named, Perl-based chat platform. Rather than "I'm going to drop my chat program into a Drupal module", I'd like to see "I want to implement the best solutions to improve the chat module." I see three possible motivations for his application, and I think they follow in the order: 1) spread Ralfchat, 2) money, 3) make a cool feature for Drupal. I'd prefer not to spend the time integrating a Perl-based chat when there several decent PHP-based ones floating around and everything else Drupal is PHP.
I've opted to avoid modules that "integrate" third party software, because I don't want to end up with a module I use a lot that relies on unmaintained third-party software. Then you end up with a module that never improves, a big conversion to a new third-party software, or a big conversion to a custom solution. In the case of chat, there's not really archived information to convert, so I'm slightly less concerned about it.
I've used phpFreeChat, but it's obviously written for standalone use, so in its case I'm uneasy about the amount of work to get it integrated into Drupal's access controls and I'd rather see features added to the existing chat than integrate third party stuff. I have similar opinions that spread into the ImageMagick topic. In this case, I'm trying to predict Ralf's effort and excitement in implementing a competing chat system for a CMS he doesn't even use and I see other applications that I'd rather throw my support behind.
The reason I’m so critical of Ralf’s application is because it’s written to integrate his self-named, Perl-based chat platform. Rather than “I’m going to drop my chat program into a Drupal module”, I’d like to see “I want to implement the best solutions to improve the chat module.” I see three possible motivations for his application, and I think they follow in the order: 1) spread Ralfchat, 2) money, 3) make a cool feature for Drupal. I’d prefer not to spend the time integrating a Perl-based chat when there several decent PHP-based ones floating around and everything else Drupal is PHP.
I agree that adding a perl chat to Drupal would be an awful idea, but I think Ralf has updated his ideas (see the e-mails above, and his latest proposal) and is now looking at using either chatbox or phpfreechat as a starting point.
I’ve used phpFreeChat, but it’s obviously written for standalone use, so in its case I’m uneasy about the amount of work to get it integrated into Drupal’s access controls and I’d rather see features added to the existing chat than integrate third party stuff.
Here I would have to disagree. If you looked at my module you would see that it does exactly what you are saying in about 250 lines of code (and 2-3 days work). phpFreeChat is ideally suited to integration, and it would be a far greater effort to duplicate this functionality from scratch.
Comments
I already wrote a chat module
AJAX chat using phpfreechat (clean code, active development, easily themable, with disk/ram based modes to minimize server distress). My module allows chat to be enabled/disabled per content type and node, gives full control of each phpfreechat parameter, and passes handling of refresh requests to a separate script to avoid Drupal bootstrap overhead.
Still got some final touches to do, but it's mostly done for 4.6. It could be upgraded to 4.7, but I doubt that is a full summers worth of work.
Possibly we could come up with some more features to be implemented - but it might be a little tough :-/
Drop me a line and we can talk about it (google page is going all '502 server error' on me).
I've sent you a copy of the student's proposal
Please take a look and see if there's overlap or if there's a possibility of this becoming a 4.7/4.8 chat module, etc.
I’ll take a look over it
I'll take a look over it and post some ideas here.
Thanks!
E-mail to Ralf:
Hi Ralf,
What can I say - great minds think alike :) I just finished work on a fully fledged chat module for Drupal 4.6 when I saw your application.
Please take a look - http://drupal.org/node/62389 - the code is in Drupal cvs: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/phpfreechat/
My current list of todos is:
* Update for Drupal 4.7!
* Add chat blocks
* Fix debug setting (which currently breaks the chat)
* Look at integrating theming (map Drupal theme onto phpFreeChat theme)
* Wait for phpFreeChat 1.0 (with /kick etc) and integrate into the Drupal access rights system
This (I hope) provides a solid base to build on for AJAX chat in Drupal. It would be great (if you are interested) for you to build on this code (rather than start from scratch). If this is the case, then one question (probably for Robert) is this: some of the ideas you suggest would involve contributing to the phpFreeChat project as much as to the Drupal integration module. I am not sure if this is allowed by the SoC project or how other Drupal folks feel about this. The todo list above would also be a great start, but is probably not a summers worth of work :)
On the other hand, if you do want to start from scratch then I was wondering what client technology are you intending to use? You mention using HTTP-streaming - which implies Java or Flash (since Javascript cannot, I think, open raw http sockets). I have done a lot of research into potential chat clients (especially AJAX and Flash) and would be interested to know what ideas you had here, or if there are any projects you would be looking integrating. Building a fully featured chat client (on any platform) is a huge undertaking, and I have some concerns about the length of time that would take.
Anyway, it's great we are thinking along the same lines!
Thanks!
- Owen
Nice, thanks
thanks for reaching out to this one. It's not really possible to work for two mentoring orgs, nor is it possible to have mentors from two orgs both coach 1 student. These ideas were tossed around a bit on the mailing lists, but I think Google would rather just keep it simple. Let us know what kind of response you get.
Cheers
This is a little different
This is a little different from the situation discussed on the SoC list, as phpFreeChat is not actually a SoC mentor org. If Ralf was selected then, apart from the work upgrading the module to 4.7 and adding chat blocks a lot of the additional features/work would actually be on the phpFreeChat codebase. Now, Drupal would obviously benefit from this, as we get a tighter integrated and more fully featured chat client (and, of course we could also pull some people looking for a chat platform to the Drupal/phpFreeChat combo). I don't see any reason why both mentors could not be from Drupal, although obviously plenty of cooperation with the phpFreeChat folks would be needed too. From reading the Google docs, this seems OK (since we are basically using phpFreeChat as a library), but I don't know what other Drupal folks think about the idea of one of our students spending a bunch of time working on 'another project' :)
I can understand both sides here, and, while I would be delighted if Ralf's (and other mentors) focus went towards improving the phpfreechat module and phpFreeChat client I would not be offended if it was decided that we wanted to focus more on Drupal. There is also the objection to 3rd party integration (with while I agree in general) I think that phpFreeChat is worth integration - writing something this highly featured ourselves would be a lot of work.
Anyway, please let me know your thoughts!
I attach two replies from Ralf (over e-mail) below.
Thanks!
- Owen
Hi Owen,
On Sun, 2006-05-07 at 23:37 -0700, Owen Barton wrote:
I wasn't aware of your module, but it looks really nice. Of course I am
always open to reuse a existing code base. At the moment, the plan is to
extend Chatbox. But your module seems to be another good alternative.
However, I received critical feedback about the usage of third party
software, so I would have to double check this.
One comment regarding the streaming. Technically speaking, it's not the
right term. I refer to a technique where you simply don't close the
http-connection, an effect you can observe when loading very slow
server-side processed pages. I have used this approach in my prior
project http://ralfchat.com. It doesn't use any other technology than
pure HTML/HTTP on the client side. Have a look at the demo to see it in
action.
Thanks for your feedback and looking forward to a fruitful
corporation ;-)
regards Ralf
Hi Owen,
On Mon, 2006-05-08 at 08:35 -0700, Owen Barton wrote:
I agree on the heavy server load of chatbox and its unsuitability for a
large number of users. These are two of the main objectives I want to
address with my proposal. The refresh method should definitely be
complemented by the mentioned streaming output. I think an interesting
idea would be to replace the HTML refresh method by a slimmer AJAX-like
callback (which is still depending on a regular refresh). The
administrator and optionally the user would then have the choice between
both output modes, similar to the options ralfchat provides. Both
methods have their advantages and disadvantages. Streaming works without
any client-side technology, in particular without JavaScript, whereas
AJAX is more likely to work with firewalls or proxies.
Today was the first time I came across phpFreeChat. It looks promising
and I like its handling. I'll install a drupal 4.6 testbed now to try
you integration module!
Yes, I agree. Especially if the integration is tight, but not bound to a
specific setup/version. If both Drupal and phpFreeChat can be maintained
and updated independently and both provide the needed plugin
functionality I don't see a reason to not take advantage of mature 3rd
party software.
That summaries the differences pretty well. BTW, during research you
might encounter the synonymous terms pushlet or server push. The
tradeoff remains, but in my point of view, Apache should be able to
balance the load and minimise the overhead of its threads better than
any cgi/php application could do. A real performance comparison might be
helpful.
Thank you for your support! Please keep me updated about the status, I'm
always thankful for new ideas and suggestions.
Regarding your second email, of course you can quote these emails to the
mentor/drupal community.
regards Ralf
ralfchat
The reason I'm so critical of Ralf's application is because it's written to integrate his self-named, Perl-based chat platform. Rather than "I'm going to drop my chat program into a Drupal module", I'd like to see "I want to implement the best solutions to improve the chat module." I see three possible motivations for his application, and I think they follow in the order: 1) spread Ralfchat, 2) money, 3) make a cool feature for Drupal. I'd prefer not to spend the time integrating a Perl-based chat when there several decent PHP-based ones floating around and everything else Drupal is PHP.
I've opted to avoid modules that "integrate" third party software, because I don't want to end up with a module I use a lot that relies on unmaintained third-party software. Then you end up with a module that never improves, a big conversion to a new third-party software, or a big conversion to a custom solution. In the case of chat, there's not really archived information to convert, so I'm slightly less concerned about it.
I've used phpFreeChat, but it's obviously written for standalone use, so in its case I'm uneasy about the amount of work to get it integrated into Drupal's access controls and I'd rather see features added to the existing chat than integrate third party stuff. I have similar opinions that spread into the ImageMagick topic. In this case, I'm trying to predict Ralf's effort and excitement in implementing a competing chat system for a CMS he doesn't even use and I see other applications that I'd rather throw my support behind.
Ideas change...
I agree that adding a perl chat to Drupal would be an awful idea, but I think Ralf has updated his ideas (see the e-mails above, and his latest proposal) and is now looking at using either chatbox or phpfreechat as a starting point.
Here I would have to disagree. If you looked at my module you would see that it does exactly what you are saying in about 250 lines of code (and 2-3 days work). phpFreeChat is ideally suited to integration, and it would be a far greater effort to duplicate this functionality from scratch.
Ok
I'll defer to you on the programming. I only played with the end-user GUI.