Re: HTML Streaming

On Sat, 30 Aug 1997 Albertfine@aol.com wrote:

> Streaming is a "technique for transferring data." "processed as a steady
> and continuous stream" is only a description.  "With streaming, the client
> browser or plug-in can start displaying the data before the entire file
> has been transmitted." This is not a result. It is an example. Their is no
> mention of "IP transmission", "refreshing of the data", etc.

Why are we dealing with "browser or plug-in can start display the data..."?
HTML is not necessarily displayed; it can be spoken, or streamed through an
SGML parser. TCP sockets are also said to be streaming but the data may not
be necessarily displayed or processed immediately.

> I think you're a little confused about streaming. As I have said before,
> it is not the fault of the browser, editor or the coder but the file
> format.
[...]

Besides the current situation with tables, there are no significant factors
that prevent "viewing while download" (which you call "streaming") with
HTML. HTML 4.0 already addresses the table issue.

In fact, HTML is not really a file format; it is a markup language.

> added to enable streaming such as with the table or img tags. They are not 

IMG elements (*not* tags) have the WIDTH and HEIGHT attribute to allow
browsers to precalculate the image size. These facilities do not exist
for other elements because the rendering cannot be precalculated.

> It would be sent first, give an overall description of the page 

Overall description of a "page" (meta data) can be specified by using the
META element.

> The extent tag is not an attribute. A browser wouldn't recognize it. For
> this to work, you would need to rewrite HTML. This is what I am trying to
> avoid.

The "stream tags" and "event tags" you propose requires the same level of
modification of HTML as this EXTENT attribute (whatever it is).

> Maybe you are thinking of the width attribute for the pre tag?
> >This worries me. You don't seem to realize that "a letter" and "a
> >space" are not finite quantities when dealing with regular type: you
> >have to know _which_ letter, because they're all different widths. It
> >is therefore not possible to perform such a calculation as you
> >envisage, based solely on the number of glyphs expected. 
> Actually, their are all the same lengths or paragraphs wouldn't line up :)

May be you are thinking of the pre element? :)

[...]
> The number of letters and spaces is actually 29. An HTML editor would not do 
> this. If it were human written code, it would be assembled by a program 
> before it could be described as a streaming HTML file. I miss you point.

Notifying the browser that there are X characters in the content of the
element does not help more than the current streaming technique employed by
browsers.

> Which old terminal?

Like this one I am using now, a text console.

> The streaming protocols are meant to describe all displayed tags not just 
> text.

The content of an HTML document and tags, etc. are counted as one entity
during transfer.

> >I'm sorry, but that statement is simply incorrect. If you analyse what
> >a browser's lexical scanner and parser (such as they are) would have
> >to do, plus what they'd have to do when they receive the extent data,
> >I think you'll find the processing overhead is greater, not less. And
> I plan to do this.

You plan to do what? Make browsers go slower?

> I think "pre-notification" attributes are important. They are used by table
> tags, img tags etc.

To clarify this issue, please give a sample implementation logic which make
use of these "attributes" and produce better results.

-- 
Steve Cheng     elmert@ipoline.com     <http://home.ipoline.com/~elmert/>

Received on Saturday, 30 August 1997 15:43:04 UTC