Server is embedded system.
User will be accessing this system from any PC browser. If I use applets user will have to install JRE . I was trying to get suggestion for implementing Real time data on web page with or without JRE.
Server is embedded system.
User will be accessing this system from any PC browser. If I use applets user will have to install JRE . I was trying to get suggestion for implementing Real time data on web page with or without JRE.
Totally true.
Yes, but why is this a big deal? Compared to the transfer time updating a whole page should make no difference. Someone else said that the update was annoying. This may be true but once you have actual new data, you can change the autorefresh tag to not do it anymore. So the annoying part is just a flag that you are still waiting for data, in fact you can display something like "WAITING" during the update.
Yes you could do that. I hate frames, and they are not done on restricted capability browsers. If you want compatibility you must stick to straight HTML.
If you want compatibility you must stick to straight HTML.
Well, except for auto-refresh.
There is no "x" in my email address.
Sure, consider this weeks really hot buzzword technology: Ajax.
While TCP support is not part of JavaScript per say, most browsers have as part of the library of function that the scripting language (including JavaScript) can call, the necessary support. Ajax uses the XMLHttpRequest object, which is supported my most browsers.
Something like this? :
There are a few problems with full-page updates. One is that you get unnecessary blinking of the page - a problem greatly exasperated if the browser window is to small to see the whole page. Good browsers on fast hardware have less of a problem here, but it can still be annoying. The second problem is that if most of the page is static, and of significant size, then it is a lot of overhead for the embedded system to send the same large files again and again.
Frames are part of the HTML standard, and have been so for a good many years. Perhaps you are thinking of HTML 3 ? There is certainly good reason for not using more advanced features than necessary - a site should not use Java unless absolutely unavoidable, it should ensure that it works fine without Javascript enabled, it should *always* avoid browser-specific code or platform specific features like ActiveX, and be usable in pure text mode (for people using screen readers, or text-only browsers). But clearly the OP has certain minimum requirements for the client browser, and frames support is not too much to ask.
Digi International also makes a similar product.
Regards Anton Erasmus
Here is an example of a WEB 2.0 application that is updated in realm time. The following contains a small server compiled for windows. The server (not the client web interface) is integrated with an MP3 player. The MP3 player sends real time data to the client (plugin less browser client). You can start multiple browser windows and have multiple WEB
2.0 user interfaces that control the MP3 player.From the site: The demo contains a multi user slide show that is controlled by the EventHandler. The demo also contains a DHTML interface to the MP3 player embedded in the server. The EventHandler pushes data in real time to the browser interface when the MP3 player is running. The demo is a self-extracting archive. It automatically starts when the files are extracted. Be sure to turn on your speaker before running the demo as the audio commentary begins almost immediately. This demo is using an older pre-release version of the EventHandler.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.