Re: Crawling info displays and slide shows (Erik Ostrom)
From: (Erik Ostrom)
Message-id: <>
Subject: Re: Crawling info displays and slide shows
To: (Rich Wiggins)
Date: Mon, 4 Oct 1993 20:53:14 (CDT)
In-reply-to: <> from "Rich Wiggins" at Oct 3, 93 08:30:12 pm
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1653      
> >Define a new Content-type: (e.g., www/slideshow), then define the protocol,
> >and then get browsers to support it.  Please Please Please don't clutter
> >up the language with stuff that is more easily and better done externally.

> 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

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.