Dynamically update screens when data changes?

[theniteowl]

Hi All,
I know this is not an easy answer question any may require desktop side programming, I am looking for any ideas on approach or examples that others have done.

I want to have a page that shows requests as they come in and I want that data pushed out to the screens of my team members. When a team member takes possession of a request I want that to be immediately reflected on everyone else's screen so they do not also try to work on the request.

I know the issue is with the immediate update part and crossing from server-side to client-side. Sure the browser can be set client-side to keep refreshing the page at set intervals but this will not be immediate and could be a performance problem. I could probably use client-side AJAX to check for changes without refreshing the page but this again comes back to performance issues.

Has anyone done something similar? Anyone found a way to maintain a link watching for a status change and triggering an event when it occurs?
I was thinking along the lines of how push email works for PDA devices maintaining an open connection without constantly sending data across and sending a signal from server-side to trigger the page update when something changes. This may require a desktop application to do though.

Thoughts?


At my age I still learn something new every day, but I forget two others.

 

[Kendel]

I think a desktop app is what you need. When a team member takes possession of a request, let the desktop app popup and let othet team members know that someone is working on that request.

I saw something like this in classic ASP & VB6.

 

[Sheco]

I don't see how to get around the problem without client polling in plain HTTP since it is a Request/Response protocol.

It sounds like you want something that works more like instant messaging than a web browser.

 

[theniteowl]

Yes, very much like instant messaging save that the client-side would recieve the message just as a trigger to update it's own screen info.

I may be able to do something with an HTA app executing directly on the client's desktop but would have to have one machine hosting the data or tying the HTA app to ASP pages on the web server. The important part is to either have the client-side polling for a status without becoming a resource hog or finding a way for the server-side to push the status change to the client.

The best environment is probably not a web based solution but desktop application development may be a bit further out of reach given experience and time constraints so I hoped to find a reasonable compromise approach web based with ASP.
Everything hinges around client-side limitations though.

Any possibility of tapping into AIM to send/receive triggers and respond with the client-side app? Never seen it done but I am sure someone must have tried at some point.


At my age I still learn something new every day, but I forget two others.

 

[Sheco]

You could maybe keep the client polling overhead really small if you used AJAX to call an ASP ... and that ASP only returned one thing: the max timestamp in your database.

Then client-side script would compare that timestamp value to its own copy of max timestamp that was set when the page was first requested.

This way you would only repeatedly ask for a tiny page but get the real refresh only when the value changed.

 

[theniteowl]

I have considered an approach like this but still wonder how much CPU time it will require both at the client's machine and on the server with constant polling happening.

Microsoft's push email works by holding a channel open on port 80 at the server but not passing data. The server waits a specified time and renews the connection but not sending data. If new mail comes in the server just sends a quick blip across the connection to trigger the remote device to download new messages. Its not truly PUSH email but it has a similar effect without sending lots of information across the connection.


At my age I still learn something new every day, but I forget two others.

 

[Tarwn]

I was just considering that method, but I have to wonder what kind of load that puts on the server. The fastest [development] method I could see would be to have a page the user sees with an XMLHTTP object. That XMLHTP object sends a page query back to the server with the latest timestamp in it's querystring. If the return status is the timeout code, you close the XMLHTTP object and re-open it, otherwise you handle the new content and restart the connection.
On the server-side you would need an ASP script that had the API call for sleep defined. It would receive a date in the querystring from the client and poll the database until something newer appears. Basically a loop of checking the databse and sleeping. If it finds something newer, it Response.Write's all the newer records (probably in XML or JSON).
You could extend the life of the page by making the script timeout larger. But I'm still not sure how the server will like all of the threads sticking around sleeping. I've heard various comments on how IIS performs when a lot of hits are coming in and the sleep command is being used.

Of course the best method would be to write a custom web server that does something like the above, but that is definately not the fast solution

-T