Re: dynamic html (fwd)
Bert Bos <bert@let.rug.nl>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 11 May 1994 15:39:02 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405111334.AA20316@freya.let.rug.nl>
Errors-To: listmaster@www0.cern.ch
Reply-To: bert@let.rug.nl
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Bert Bos <bert@let.rug.nl>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: dynamic html (fwd)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL13]
X-Mailer: ELM [version 2.4 PL13]
|> one could imagine documents that go like this
|>
|> <include refresh=3 src=URL>this will change soon</include>
|> <include refresh=5 src=URL>this will change a bit later</include>
|> etc
|> and using the expire date in the data requested via the include URL to
|> effectively reset the refresh time to the next century one would have
|> implemented a clean way of delayed loading.
|> people viewing such a page would first see a simple version and as time
|> passes will gradually see a more expanded document (prossibly with large
|> inlined images).
|>
|> other ideas come to mind:
|> <include refresh=10 src="URL">this is some text</include>
|> <form action=....>
|> <textarea ...>
|> </form>
|> and depending on the cgi script behind the url's you would have an
|> interactive communication : I write something in my textarea, submit
|> the form, write it somewhere an other user can read it via a
|> refreshed include, and I will retrieve your submitted text every 10 seconds
|>
|> or:
|> <include refresh=5 src="URL"><audio src=""></include>
|> This asumes we finally get inlined audio (don't make it too difficult, just
|> play the sound when the page is presented to the user).
|> If the audio sample is long enough, and the connection is fast enough you
|> have some kind of radio station. (not good for music but for speech where
|> breaks after sentences are not too bad this seems a good idea)
Does this really require a REFRESH attribute? It seems that everything
except the delayed loading would still work if the client only used
the Expires header of the included document. I can see that delayed
loading is nice, but in practice I think it would nearly always be
refresh=0, because it is to much work to keep the expire rate of the
external doc and the refresh attribute in step and to keep the
contents of the INCLUDE element coordinated with the contents of the
external doc.
Bert
--
__________________________________
/ _ Bert Bos <bert@let.rug.nl> |
() |/ \ Alfa-informatica, |
\ |\_/ Rijksuniversiteit Groningen |
\_____/| Postbus 716 |
| 9700 AS GRONINGEN |
| Nederland |
| http://tyr.let.rug.nl/~bert/ |
\__________________________________|