Re: HTML Streaming

> Okay :) Lets try this one more time. I have taken classes on this stuff.

Then I'm surprised you haven't grasped it yet.

> http://www.cnet.com/Resources/Info/Glossary/Terms/streaming.html

It says:

   When data is moving fast from one chunk of hardware to another, and
   it doesn't have to wait until it's all in one place for the
   destination device to do something with it, it's streaming. When
   your hard disk's data is being written to a tape backup device,
   it's streaming.  When you're watching a QuickTime movie on the
   Internet, it's not, because it has to be fully downloaded before
   you can play it.

I agree. But I repeat (for the last time, I'm afraid: I have work to
do) that your proposal does not address the streaming of data (the
evening out of the datastream on arrival so that a subsequent device
can process it in real time without pause). Under your proposal the
browser would "know" the length of an element when the EVENT element
arrived, but it would still not control or manage the arrival of the
data itself.

I said:
> >That would certainly be another possibility. But you still haven't
> >done anything about the _rate_ or steadiness at which the data arrives
> >at the browser end.

> YES! Please, consider this other possibility. Please do not bring up
> anything related to the definition of streaming again. I am sorry I
> brought it up. I thought it would be an easy way to understand what
> I was talking about.  Apparently, it is not.

It's not because you were not talking about streaming.

> I don't think proposing a new attribute for every new tag or tag
> that does not already have an attribute is the most efficient way to
> deal with this problem.

Then I think you need to examine the way in which SGML processors
handle data.

> Many tags do not have an attribute that allows it to be predefined
> by the browser. My proposal is a separate listing, the events tag,
> and a uniform description of sizes, content etc. Your proposal
> rewrites many tags. I just add a single tag. I would not consider
> this a major rewrite.

It's not a tag, it's an element. How many times do you need to be
told this?  Please supply the DTD code to show where this EVENT tag
fits in the HTML structure. I propose adding to %coreattrs; (HTML4):

   EXTENT   NUMBER  #IMPLIED -- number of data characters in element --

This does not involve altering any content models, which you would
need to do for adding an extra element.

> No insult, but I really don't want to read your book. As I have said, I 
> already took a class.

I'm sure it was very good.

> But the space given to the i and the w are the same. Really! Try it.

Either you are blind or you are using a fixed-width font. The i and w
are different widths in all other fonts. Measure them in pixels if you
don't believe me: I have put an example snipped out of Netscape at
http://imbolc.ucc.ie/~pflynn/text.gif -- go and look hard at the w and
the i in the second line and then measure them carefully.

> Stick it in an HTML file and see how it is displayed.

That's precisely why I quoted the byte size as I did, to illustrate
the pointlessness of giving it as a value. 

> I am glad you think my proposal has merit. Are you one of these gureaux?

Nope.

> If you mean, adding an attribute to every tag that does not have it and every
> new tag that comes along; I don't think this is trivial.

Nor is adding an extra element. You have to define where it goes, and
you have not done that yet.

///Peter

Received on Sunday, 31 August 1997 16:59:52 UTC