- From: <jerryj@datametrics.com>
- Date: Sat, 29 Jun 1996 11:50:30 -0400
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I was looking at "http://fy.chalmers.se/~appro/SITE/draft-ietf-http-v11-spec-00.html" and noticed that there was a section on "Refresh" that was not yet written. My concern with "Refresh" is that I do not want it to be a global concept (a browser can only keep track of one refresh)--it looks to be implemented this way in Netscape 2.x. I would like "Refresh" to apply to individual objects (RE: the message below to netscape). This would allow individual GIF's within a document to be refreshed. Thanks - Jerry Jongerius (jerryj@datametrics.com) ---------- From: jerryj To: 'MHS:pushpull@netscape.com' Subject: Client Pull comments Date: Saturday, June 29, 1996 10:59AM Help! I have a great use for client-pull, but it is not working. I have an html document with 10+ GIF images. In the HTTP response header for each GIF (not the text html), there is "Refresh: 5". You can see what I wanted to do!--I wanted NetScape to update each GIF within the document every 5 seconds, but it does not work. Instead, what I see is that 5 seconds later, I see my document replaced by only one of the 10 GIFs. Why is "Refresh" implemented as a global concept in NetScape? [It seems to launch a new document]. Why not instead assign "Refresh" TO AN OBJECT (NOT GLOBAL). If the object to be refreshed is an html document, refresh the document. If the object to be refreshed is an object WITHIN a document, update the object WITHIN the document (and do it smoothly, no flicker). I could use server-push, but this requires extra coding. Also, there is a potential for a new socket connection for each image, which I want to avoid (since I could have a LOT of images within one document). I would really like to see this implemented. If there is anything that I can do to help, please let me know. Please respond and let me know what you think and does this have any chance of being implemented. Thanks. - Jerry Jongerius (jerryj@datametrics.com)
Received on Saturday, 29 June 1996 08:59:16 UTC