I wrote a new CommSystem module in my 5.0.2-MMBRICH branch. The comm
system is a full replacement for the chat system from RC1 and also adds
a host of API's to manipulate it from your favorite external system or
vtiger module :).
Here is a short list of features, any testers or patches to help move it
along are appreciated.
1) Full P2P chat
2) Session/Off-line messaging capabilities (ie: if a new message comes
in right when you click on a link in the system, when the new page loads
you will see the message that appeared as the page was being reloaded).
3) Follows your window focus. If you have multiple tabs open in the
CRM, you will only get new messages and status messages in the focused
window. All messages are cached when there is no focus on a CRM window.
4) Alert/Event messages. An "MSN like" status box that appears at the
bottom of your browser to alert about new emails, voicemails, incoming
calls, etc. It has pretty effects to make it slide in and out for
5) "User is typing" status messages.
6) Email messages from either periodic checks via JSON or can also be
injected via scripts. (Ie: incoming emails to [hidden email] could
be announced to users x,y and z)
7) Simple CommSystem.php and CommSystem.js classes to manipulate the
alerts and chat system. CommSystem.js is wrote to follow prototype
standards as much as I could get it to.
1) Finish the group IM feature.
2) Lots of ugly, needs UI work.
3) Support Portal integration ("Chat with Live Help" links in the
4) Message archives so that old messages can be deleted from the CRM
(maybe a monthly cron script to backup and delete the messages from the
5) Asterisk AGI Script and SOAP functions to inject Voicemail or
Incoming call alerts
6) Cron scripts to populate email alerts?
7) Fix annoying bugs (Ie: '\n\r' breaks sending messages)
9) Test, test, test
10) Jabber connector?
Drawbacks to this system:
1) Makes a request to the server every N milliseconds to check for new
messages, alerts or status updates. This gets heavy on the server. One
way to take load off the server is with the focus tracking mentioned
above. Un-focused windows will not make requests back to the server.
Another way is to create a decay timer like the one used in the
prototype Ajax.PeriodicalUpdater() class. This basically checks the
last output status and compares it to the current output status. If
they are the same then N = (N*<decay amount>) and if the current output
status is diff than the last output status N=(N).
2) The whole system is one large timer loop and global references to the
CommSystem.js class have to be created to access the class within the
loop. This is a memory usage issue but shouldn't be too noticeable for
3) Probably a 70% client side and 30% server side system. Thats a lot
If you get a chance to check it out, let me know what you think and if
you'd like to see something like this in vt5 going forward.
Get started with creating presentations online - http://zohoshow.com?vt