Drake Smith wrote:
I use Twisted Web on an embedded Linux device to provide browser-based configuration & control. The browser displays a bar graph of a parameter that is quickly changing on the embedded device (peak audio level). In order to provide a reasonable feedback to the user, the browser connects to the Twisted Web CGI server once a second via XMLHTTPRequest to obtain an updated bar graph level, then Twisted Web dutifully closes the connection. Is there a way to achieve the same thing without opening & closing a connection each time?
AJAXy things in nevow.athena may be attracting to you, as pointed out elsewhere. If you for some reason don't want to use them, the old school way is to have the bar graph as a GIF with more than one frame, and stream the frames whenever you want to update the picture; that keeps a single connection open to the server, pushing more data exactly when you want to. Of course, it is limited to updating 1-4 GIF images.
At 11:22 AM 12/18/2005 +0200, you wrote:
Drake Smith wrote:
I use Twisted Web on an embedded Linux device to provide browser-based configuration & control. The browser displays a bar graph of a parameter that is quickly changing on the embedded device (peak audio level). In order to provide a reasonable feedback to the user, the browser connects to the Twisted Web CGI server once a second via XMLHTTPRequest to obtain an updated bar graph level, then Twisted Web dutifully closes the connection. Is there a way to achieve the same thing without opening & closing a connection each time?
AJAXy things in nevow.athena may be attracting to you, as pointed out elsewhere. If you for some reason don't want to use them, the old school way is to have the bar graph as a GIF with more than one frame, and stream the frames whenever you want to update the picture; that keeps a single connection open to the server, pushing more data exactly when you want to. Of course, it is limited to updating 1-4 GIF images.
Thanks for chiming-in Tommi because keeping the connection open is really where I was leaning. I never had any luck doing this with Python's CGIHTTPServer module but I expect this will be no problem with Twisted Web or at least Twisted Web2. I am eager to revisit the "open connection" approach in light of JP's implication that AJAX-like functionality does not necessarily reduce the traffic between client & server -- my original goal. Be that as it may, athena.livepage is such an improvement over HTTP's request/response model that I will pursue that as well.
On Sun December 18 2005 04:22, Tommi Virtanen wrote:
the old school way is to have the bar graph as a GIF with more than one frame, and stream the frames whenever you want to update the picture; that keeps a single connection open to the server, pushing more data exactly when you want to. Of course, it is limited to updating 1-4 GIF images.
This is a really great idea! Are there any gotchas that should be mentioned? Does the GIF header not specify the number of frames? And even if the GIF isn't looped, would browsers be smart enough to discard data from previous frames? It seems like it might cause what would effectively be a memory leak on the browser. Just wondering whether this is suitable to be applied whenever you wished you could just write to a frame buffer on a client, or if it should be used sparringly for brief special effects. Mike.
On Tue, Dec 20, 2005 at 03:07:49PM -0500, Mike Pelletier wrote:
On Sun December 18 2005 04:22, Tommi Virtanen wrote:
the old school way is to have the bar graph as a GIF with more than one frame, and stream the frames whenever you want to update the picture; that keeps a single connection open to the server, pushing more data exactly when you want to. Of course, it is limited to updating 1-4 GIF images.
This is a really great idea! Are there any gotchas that should be mentioned? Does the GIF header not specify the number of frames? And even if the GIF isn't looped, would browsers be smart enough to discard data from previous frames? It seems like it might cause what would effectively be a memory leak on the browser.
Yep, I believe it does slowly eat memory. In theory browsers could discard old frames, but I don't think any are smart enough to. Of course, I've no idea if more modern AJAX stuff is any better in practice ;) -Andrew.
Mike Pelletier wrote:
This is a really great idea! Are there any gotchas that should be mentioned? Does the GIF header not specify the number of frames? And even if the GIF isn't looped, would browsers be smart enough to discard data from previous frames? It seems like it might cause what would effectively be a memory leak on the browser.
The standard trick is to make the containing html page (or iframe) refresh itself every once in a while, to free the memory etc. I've written a (prototype of a) video surveillance system long, long ago in the era of Perl CGIs, with this basic architecture. It worked well enough to never cause any negative feedback.
Just wondering whether this is suitable to be applied whenever you wished you could just write to a frame buffer on a client, or if it should be used sparringly for brief special effects.
For generic use, nevow.canvas, SVG+CSS+AJAX or XUL (nufox?) or something like that sounds a lot better.
Mike Pelletier wrote:
This is a really great idea! Are there any gotchas that should be mentioned? Does the GIF header not specify the number of frames? And even if the GIF
Dug up old code with more concrete things. Now that I look at it in more detail, there were problems with multiframe GIFs, so I ended up doing this: HTTP/1.1 200 OK Connection: close Content-type: multipart/x-mixed-replace; boundary=--myboundary Pragma: no-cache Cache-Control: no-cache --myboundary Content-Type: image/jpeg <put a jpeg here> --myboundary <delay for e.g. 5 seconds here>Content-Type: image/jpeg <put a jpeg here> --myboundary etc etc.. just make sure you close that stream at some point, at least at that time Netscape on windows did not obey refreshes dictated by HTTP headers if the page contained an <img> that was still being pushed.
participants (4)
-
Andrew Bennetts -
Drake Smith -
Mike Pelletier -
Tommi Virtanen