W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1999

Again: Updating

From: Fabian Wein <wein@iis.fhg.de>
Date: Tue, 01 Jun 1999 14:02:17 +0100
Message-ID: <3753D9D9.4CCA127C@iis.fhg.de>
To: www-talk@w3.org
Hi gurus on this list,

I come up again with an issue I brought some weeks ago:

For a DAB (Digital Audio Broadcasting) app a local/remote browser
displays webpages via an own, still have to write, http server.

When objects (html, images, slides) are updated via air the browser
has to display the new version.

I use "META HTTP-EQUIV="Refresh" CONTENT=5" or "Refresh:" in the http
response (yes, this works even when not in standard). But IE and NS
flicker and Opera is fine. Has a lot of connections! :-(

I use mime/multipart, works fine for NS but not IE and Opera. Has a lot
of open connections :-(

I control the browser. Works only with IE and local (when I just 
require a browser and not an own application).

I controll the browsers communication via java or javascript and maybe
even WFC.

When I receive an altered object via air...

I either must know if this object is currently displayed and then force
the browser to refresh as in 3) or 4)

Or the browser "asks" for updates as in 1) and 2)

From 1) to 3) is not nice and works only for one browser each. Is it
even possible for NS to hold open multipart connections for a lot of
inlined images?

If I could gain controll over the browser via 4) I could implement all
ideas for all browsers and could add another approach where I have 
a very simple client/server solution: If an object is altered the 
server asks the clients if they currently display this object and if
so order them to do a reload.

I'm quite sure this is not an extraordinary problem and there already
are some solutions out in web space.

If you have any ideas or comments ... please ... :-)


Dipl. Ing. Fabian Wein                Phone +49(0)9131/776-653
Fraunhofer IIS (Integrated Circuits)  mailto:wein@iis.fhg.de
91058 Erlangen (Germany)              http://www.iis.fhg.de
Received on Tuesday, 1 June 1999 07:59:54 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:23 UTC