Maintenance Log and Chat function

In the situation where more than one person is logged on to mango and potentially operating the same piece of equipment (say they are both responding to the same event/alarm) the two people need a means to communicate with each other.

It is preferable to use mango to pass the messages back and forth so that they can be logged and displayed to other users that may logon later. A bit like IRC. A record of the response to a given event can be created.

If the conversation takes place in an external IM program then the record of the conversation is lost. Voice conversations may also take place but specific operations, analysis, or conditions that need to be recorded could be entered via the "chat" log or maintenance log.

This is a bit different from User Comments:

User comments are attached to a point whereas the maintenance/chat/operator log I am envisioning would be associated with the entire system or mango instance

the messages would need to be immediately displayed to all other users logged on

when a user logs on they should be able to review the log of messages passed back and forth between the other users without having to navigate to the point details.

The messages could be stored in the user comments table.

Should I create a 'dummy' point to associate my maintenance/chat log messages with and then modify the html pages to suit or does anyone see a better way?

Thanks for your thoughts
C

Hi Craig,

As usual, an interesting idea. I personally wouldn't try to fake anything out regarding saving the data (i.e. creating a dummy point). It probably wouldn't be too hard to create a "system log" type of user message.

The larger problem would be the online management of messages though. Besides the obvious issues with where and how to enter and display them, the transmission needs thinking through. The existing polling methodology in Mango would do the trick conceptually, but doing the implementation "properly" would require a good deal of refactoring.

As you probably already know, when you are on, say, the watchlist, there is polling to get point data, but also separate polling to get alarm data. Adding a new polling type would make for a great deal of polling, to be sure. A better approach would be for the browser to register what data it wants from polling, and to return more generic messages that can be routed appropriately (i.e. point data to the watchlist, alarm data to the header, user messages to wherever). (It also provides an opportunity to consider a long-poll approach as well, but that's another topic.)

Perhaps I will start by creating a new dwr method that can return both the alarm data and any new messages. That would allow me to get the obvious issues sorted out without refactoring too much.

Creating a system log type of user message is a good idea, thanks.

Our current web site uses the long-poll method. It only has a handful of users so it is not a problem to have a thread sleeping until new data has arrived to send to the browser. For heavy users of mango maybe having 1 thread per logged on user would turn into a problem? I don't really know how heavy threads are.

Our current website uses the 'register' method you describe. The list of points requested by a JSP page at a specific URL and session ID is stored. When any of the points in the list are updated, the servlet wakes up and sends it to the browser. A bit of javascript updates the appropriate DIV.

For mango I'll dig into views.js so the same callback can handle lists of PointViewStates and WatchListStates (and probably more types I haven't encountered yet)

Cheers,
Craig

Hi Craig,

Note that Mango 1.6 replace the regular polling with a single integrated long poll. To add the messaging would now mean only extending the code that manages the long poll (MiscDWR et al).