/rich:
> I want to be able to deliver a pageful of text to the user, and after a
> timeout send the subsequent page. If I follow this, you want to
> relocate the functionality to the client side from the server.
> Your scheme forces me to invent a new mechanism, whereas it seems
> natural to me to want to deliver followon text after a timeout.
I think I must have missed your proposal for a timed-display system
that doesn't require a new mechanism. Tony's idea requires a new
content-type (www/slideshow) for MIME; another idea I've seen requires
adding a new tag or tag attribute (requiring in-client timing) to
HTML.
It seems to me that we're inherently talking about new functionality;
we're just discussing where to put it.
> I don't understand how this "clutters" the language. Can't the
> HTML document metaphor embrace temporal aspects?
It could; it doesn't seem compelling that it should. Putting this
functionality in HTML and not in HTTP (or MIME) means that we don't
get timed display of any document type except HTML. Of course,
putting it in MIME and not in HTML means that we don't get timed
display for documents fetched by protocols other than HTTP (unless we
define another file extension to guess at). But to me, doing slide
shows that include GIFs seems much more useful than doing slide shows
that are all HTTP but fetched via FTP.
Tell me if I'm way off-base here.
--Erik