Re: HTML Streaming

pflynn@imbolc.ucc.ie (Peter Flynn) wrote:

>That page confirms exactly what I said: "A technique for transferring
>data such that it can be processed as a steady and continuous stream".
>It can apply to text just as it can to audio and video. It involves
>using techniques to overcome the blockiness of IP transmission:
>"viewing while downloading" is enabled as a _result_ of streaming, it
>is not a definition of streaming itself. You need to get this
>distinction very clear.

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.

>Incidentally the above page is a textbook example of poor design: the
>use of tables and graphics prevents the page being displayed until all
>the elements have been received, so if anyone wanted proof that Albert
>is right to want pages displayed as they arrive, here it is. I'm just
>arguing that using a streaming protocol is not the solution: browsers
>could do it right now if they made better use of HTML, and if authors
>took more care to make their pages viewable.

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. For

example, a wav file is not designed to be heard "before the entire file has 
been transmitted" so you don't get a "steady and continuous stream." Viewing
a
page in a "steady and continuous stream" is a consideration and attributes
are
added to enable streaming such as with the table or img tags. They are not 
added to all the tags and their is no overall description of the page. I
think 
their should be a general description for size and other attributes that
should
then be added to the events tag in the head. It would be sent first, give an 
overall description of the page and attributes wouldn't need to be added to a

new tags or existing tags.

>I can do this today with a simple macro in any decent SGML editor 
>(and by adding an attribute to P such as EXTENT NUMBER #IMPLIED).

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.
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 :)

>Consider the following paragraph:
>
>   <p extent="32">I wandered lonely
>   as a cloud.
>
>The content of the P element is 32 characters (including the 3 spaces
>after the linebreak because I've indented it). That includes the 6
>characters of "lonely". The content of the FONT element is 6
>characters only. How is a browser expected to make a calculation based
>on the value 32?

Your paragraph would look like this;

I wandered lonely as a cloud.

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.

>Would it be fair to compare this to the way in which an old terminal
>used to stream the text across the screen because it displayed each
>character immediately it was received? 

Which old terminal?

>I agree completely that it would be nice to enable this on slow lines.
>I'm not certain that it's needed on anything faster than 28.8 because
>the speed at which text arrives is faster than a human can read. What
>_is_ needed is to go back to the days of _de_synchronizing images from
>text, but I've already given three reasons why browsers won't do this.

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

>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 don't have a streamed paragraph: you have a paragraph bearing a
>form of pre-notification of its size in bytes -- which I submit is not
>a meaningful or useful piece of information. Your proposal does not 
>consider the use of a streaming protocol at all.

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

>There certainly would be. Have you actually looked at a non-trivial
>piece of SGML markup?

Yes. The degree of error is hard to predict without knowing what the browser 
is doing. I plan to have a copy of Cougar modified.

>I'm sorry if this is a bit negative, but I really think your proposal
>needs a lot more work, and it needs to use more accurate terminology.

As I have said from the start, it is still very early in development.

>It would certainly be possible to streamline the display of text by a
>browser so that it appears on-screen in real time. Your proposal does
>not consider the irregularity of IP packet arrival, which would make
>the display very stop-start, and you need to take that into account
>and include a proposal for changes to the transmission protocols to
>make the data stream at an even rate (_that_'s what streaming is).

"Steady and continuous" does not mean "even." To have a "Steady and 
continuous" stream their is a lot of compression, a lot buffering and the 
way the data is sampled and sent is far from "even."

>But the biggest change you need to propose is that browsers should be
>able to pay more attention to the markup, and I think you'll find this
>hard to pursue. The markup changes needed are trivial and could be
>implemented very simply by using an extra attribute and teaching

I don't think a complete review of tags and attributes is the best thing to
do.

>editors to keep its value updated with the byte count of the current
>content: but I still feel that this is not a useful value.

Why would the editor want "to keep its value updated with the byte count of
the current content?" What does that mean anyway?

>I think what you may need to do is write your proposal in the form of
>a draft RFC first, and have it discussed: then see about getting
>someone to sponsor it through the W3C when it's nearer completion.

I thought coming to this list to discuss HTML streaming, while in 
development, would be beneficial.

Albert Fine

Received on Saturday, 30 August 1997 13:50:00 UTC