I was exited to see the approach you took in version 1 of this module as I think the biggest concern for any high-use site is the performance hit you have with many thousands of users having their browsers continuously send request for updates to your servers. The light-weight approach for using static html files for the updates allow you to avoid the whole drupal bootstrapping process and the inevitable db hits to get the updates. To my surprise, version 2 opts for the heavy weight approach of storing and retrieving the updates from the database. Consequently, version 2 of this module is not an option for all but the smallest of sites. I would strongly suggest you reconsider this direction.

Comments

kevin hankens’s picture

kevin hankens commented

Haha, yeah, it's definitely way too heavy weight :) I was experimenting a little bit to see how effective it would be to let people easily extend their updates. Though, I wonder if the update node could be cached and quickly served via static html.

I think that when this module gets updated to D7, it needs to define a new entity that can be extended with fields. Then the entities need to be served as text files like v1.x.

Thanks for the feedback!

dreed47’s picture

dreed47 commented

IMHO, extending the updates with cck fields has limited usefulness. If you use a wysiwyg editor like ckeditor then you can add images and other files like videos to the update body with version 1. The 4 features I'm looking at adding to version 1 of this module include:

1) update moderation
2) tracking and show the user that did the update
3) allowing the ajax load call for the static files to be served from a different server than the one that served the web page.
4) mark an event as closed or ended and provide a way to stop the JS from pinging the server for updates

meecect’s picture

meecect commented

I think this module would be great combined with a comet-like server to do push updates. Check out 'hookbox' for an example, and I believe there is a hookbok api module brewing on d.o as well.

The advantage is that you completely eliminate the polling aspect, and just push out the required messages to the subscribers who need it.