Re: HTML Streaming

Albert Fine writes:
[me]
> >No, streamed audio or video data is quite common.
> 
> No, streaming means to view while downloading. Go to
> http://www.pcwebopedia.com/streaming.htm

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.

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.

[Albert's example of "streaming P"]
> http://lists.w3.org/Archives/Public/www-html/1997Aug/0355.html

   It would be impossible for the HTML editor to calculate the size of
   the rendered elements considering the variety of browser, setting,
   screen size etc. The HTML editor would add general information about
   the content of the tag. The browser would then precalculate the
   rendered element based on its own settings, screen size etc. 

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

BTW, you're going to have to get your terminology right and start
talking about elements, not tags. Tags don't have content: they
delimit it.

   For example, let say you have a HTML file with a paragraph
   tag. Within the paragraph tag are 200 letters and spaces. The HTML
   editor creates an event tag that looks something like this <event
   p=200>. 

I don't see why you need to add an empty element to do this when an
attribute will perform the same function and add less overhead to the
parse. <P EXTENT="200"> would seem to make more sense.

   The browser knows it default font setting, screen size etc. It
   calculates the space required to display 200 letters and spaces
   before the actual download. 

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. 

Consider the following paragraph:

   <p extent="32">I wandered <font size="+7" extent="6">lonely</font>
   as a cloud.</p>

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?

   You would not see the scroll bar become smaller as the texts load,
   only the text stream across the screen. 

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? 

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 browser is required to do less because of the general
   description in the event tag. You have a streamed paragraph :)

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

   Of course, the general description becomes more complicated when
   you begin to do more things. Their would probably be a degree of
   error for some tag descriptions.

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

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

> The W3 excepts recommendations from individuals. I am trying to find a co 
> author that is a member. Anyone interested?

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.

///Peter

Received on Saturday, 30 August 1997 06:01:51 UTC