Hi Wim, > From the information you provided, I assume that the application would > have some internal state (a simple form could be message counters), which > is updated from a message bus (the real-time aspect). This internal state > can be queried from a web-browser and from time to time (i.e. not realtime) > you want to display the updated internal state on a web-page, with a visual > indication of which fields have changed. > Correct me if I'm wrong...
This is correct. Sorry for not making it clear. > Now, starting from this assumption, I would suggest to use a WTimer (e.g. set > at 1 second, or 5, or whatever), and connect the timeout event to a method > that reads the internal state and updates the rendered widgets, also setting > some visual feedback (background color, or something that flashes) for those > fields that have changed. This sound like a good approach and this is something I have previously played about with in another web technologies. > Concerning the real-time aspect, run the real-time tasks in an appropriately > scheduled thread, separate from the Wt threads. When the timer times out, you > could consider (this depends on your particular requirements) extracting all > necessary information from the internal state without calling Wt functions at > that point, and as such you can make the time that you hold the lock on the > internal state deterministic. In a second phase, you render the extracted data > using the Wt API. Again this sounds similar to what I have been thinking about. When the Wt application starts I was going to spawn a worker thread. This thread will take care of the connection to our messaging system. When the user enters an identification for the items they are interested in I would notify the worker thread of this fact and start the Wtimer. At some point (hopefully very quickly) the messaging system would respond with an answer (the initial state) followed by updates. When the timer times out I would request for the current state for the given item and display the response after carrying out any data manipulation that would be required. The next time the timer times out I would expect to be able to work out what has changed and only send minimal data back to the client. So for example if nothing had changed I wouldn't send anything back to the client. > Now, if you have multiple sessions looking on the same data, you'll probably not > want every session to query that structure like that. You can program your way > around that, e.g. by sharing the extracted data between sessions. Alternatively, > we already considered writing a data model (in the MVC sense) that allows to be > accessed from multiple sessions, but that does not yet exist. Multiple sessions will have the opportunity to look at the same data, but I'm happy to have each session maintain their own state as I expect the data structure to be very light. I hope this makes sense and thanks for the reply. Regards, Marcus *** IMPORTANT NOTICE *** This message (including any attachments) is confidential and is for the intended recipient only. If you are not the intended recipient, please inform the sender and delete any copies from your system. Internet communications are not secure and therefore Winterflood Securities Ltd does not accept legal responsibility for any of its contents (including any attachments) and any view expressed by the sender as these are not necessarily the views of Winterflood Securities Ltd. Although all emails sent and received by Winterflood Securities Ltd are passed through extensive virus scanning technologies, we cannot guarantee the email (including attachments) is virus free. You should take whatever measures you deem appropriate within your organisation to ensure maximum protection. Registered Office: The Atrium Building, Cannon Bridge, 25 Dowgate Hill, London, EC4R 2GA. Registered in England No. 2242204. Winterflood Securities Limited is authorised and regulated by the Financial Services Authority. ------------------------------------------------------------------------------ _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
