Pushing image to browser cache using web sockets (may require QtWebKit knowledge)

[bob2oneil]

I have a web page that is currently using a timer mechanism to update the source of an image element <IMG> to allow the browser to repaint to retreive a dynamically created image and render it at a 10 to 20 fps rate. This currently involves an HTTP request and response from the browser, with all the HTTP overhead. What I would like to do is push the update image content from the server rather than have it pulled using something like web sockets, using binary data to the browser cache, and then after the content is cached, then the img.src value is changed, the browser would somehow know that the updated image has been already cached and not attempt to retrieve it from the server. The application will require JavaScript to be active and enabled in the browser.

Anyone, perhaps with QtWebKit knowledge, know of a means of filling the browser cache using say JavaScript and web sockets, and having the cached content somehow identified by the browser so that when the image source value is specified to some handle, it will not perform an HTTP request and response for the update image content.

The question really has less to do with the transport of the updated image using web sockets, and more to do with how browser caching works, and how one might populate content using JavaScript, and how the cached content is somehow mapped to a reference URL to prevent the browser from having to retrieve cached content.

[wysota]

Have you seen QAbstractNetworkCache and its subclasses?

[bob2oneil]

Hi Wysota, thanks for the response. I am not aware of this particular class. Is this class perhaps used as part of the QtWebKit for building a browser, where the QtWebKit was the basis of the Chrome browser before Google diverged? I need my server and client side JavaScript image push technology to work with a range of OEM browsers, and it is the known limitations of file i/o under JavaScript sandboxing, and well as how to fool the browser into knowing that a particular URL set for an IMG SRC tag actually maps to something that is cached is where I am lost. Clearly the browser caches images to a local cache so that for future retrievals from a URL, it knows that it already has a copy. I want to be able to poke into that process and push a retrieved image into browser cache using a low overhead process such as web sockets to prevent the HTTP request/response overhead. I may be asking for something that it not possible to do with sandboxed JavaScript for a range of OEM browsers, and APIs are not available in the browser to do this. If that is the case, then the answer is it can not be done.

[wysota]

After reading your posts I'm not sure I understand what your question is. Are you writing the server or the client side?

[bob2oneil]

Hi Wytold, the server side only, and the JavaScript that is provided to the client browser, which is sandboxed and runs within an environment where file i/o is not consistently supported by browsers. The browsers themselves that need to be supported are more recent version of IE, Chrome, and Firefox. I looked a bit into some of the web storage capabilities associated with HTML5 (http://www.html5rocks.com/en/features/storage), but what I really need is some way of using something like web sockets to push an image file to the browser, and somehow that "tricks" the browser into knowing that when the SRC element of an IMG HTML element is changed to a particular URL, that instead of doing and HTTP request for the update, it knows that it already has the image cached. My goal is to try an remove the HTTP overhead for updating an image at say a 20 fps rate. As I think about it, the goal of most browsers is to limit what can be done by JavaScript, so it may be that it is not possible. I think perhaps the QtWebKit, which is the basis of a browser, might be the only place I can think of going to determine how the browser caches content, and whether or not it is possible to hook into that process through JavaScript.

[wysota]

Basically the server can send an "endless" response to the client whenever it needs to push additional data. If the client is smart enough it can process the incoming data, detect an "end of message" mark, process the data (by applying it via javascript to an element) and still expect more data on the same connection to arrive.

Wikipedia offers a number of approaches to pushing data into web clients: http://en.wikipedia.org/wiki/Push_technology

[bob2oneil]

Thanks, I am familiar with this technique which is sometimes referred to as "long lived connections", as well as push techniques using web sockets, which is lower overhead. The question I have is not so much how to push content, say an updated image, but to find a way of mapping something pushed to what I would like to be browser cache, so that when the "src" property of the HTML IMG element is set to a URL, that the browser then says, hey I already have that image update cached (through the server push technology), and I do not have to perform an HTTP request to the updated URL to get the update. Since JavaScript can not perform file I/O on the client, it would have to be pushed to browser memory, but at the same time, it needs to somehow get mapped such that the browser knows to identify some URL provided to the "src" property with the pushed content. Part of the challenge is this technology would have to work across the major browsers: IE, Chrome, Firefox. All I can think of is to look through the QtWebKit source, as it is the basis of some browsers for an answer. I can also accept the fact that this level of control was never to be given to a JavaScript application in the interest of security.

[wysota]

I don't think a websocket content is going to be put into a browser cache as it is not received via HTTP protocol and does not have a URL that would qualify it for storing in a cache. Therefore I think your best option is to receive the data and apply it to an image element (e.g. using the data: scheme)

[bob2oneil]

It would be my JavaScript code handling the web socket data reception on the client side, and the idea if that there might be some API available to the browser, perhaps part of the DOM where I can store the data such that the browser understood the URL mapping. It is a stretch, I have to admit, but thought it was worth the discussion. Even if there is no immediately evident solution, the conversation is worthwhile it that it lets me know the limits of the technology, so you live with what you can accomplish.

Thanks as always for the dialog.

[bob2oneil]

Looked into the data: URI method you described, and it does look like a possible solution, encoding the image content itself into a base64 string, the problems with this technique is that it appears to be limited to 3K, and my images might exceed this side, and the IE support appears to be a bit questionable.

Nonetheless, your suggestion is probably about as close as anything approaching a solution.

Thanks.