Re: Connection Header

On Sun, 18 Dec 1994, John Franks wrote:

> According to Rob McCool:
> > 
> > Yes, and to that end we have to keep in mind that while <img width=N
> > height=M> is useful, it means that in order to see that performance
> > win, everyone has to edit their HTML. That will take time, and
> > Netscape's perceived performance works everywhere without having to
> > edit (or parse) every single HTML doc on a server...
> 
> This is a very important point and one that I hadn't fully considered.
> Since the WN server keeps information about files in a data base and
> parses the header of an HTML doc when it is entered in the data base
> (to extract title and <meta> information like Keywords and Expires) I
> had in mind parsing the whole doc at that time for information about
> images.  But, but I am not sure how NCSA and CERN httpd would handle
> this.  Since the vast majority of HTML docs served on the Web are
> served by NCSA and CERN httpds we need something that can easily be
> made to work with them.  I don't think it is reasonable to expect
> authors to add the height and width.  Well, it may be reasonable, but
> it is not realistic.

No, not reasonable.  Too much opportunity for information to be out of
date or impossible for the user to obtain.  Even tools are problematic
since the image may not be local to the user.  I'm hearing my consulting
clients tell me that they edit HTML on platforms which may not have
access to the WEB, etc.  I think it is useful to allow for coding
information in the document as in <IMG ...> etc but that is really
more useful if scaling to fit is included and as a specification of
expected scaling.  For basic size it ought to be the court of last resort.

I just know I've missed a critical piece of configuration information 
for the CERN and NCSA servers vis a vis telling the server how to know
what kinds of formats are available to use in the content type
'negotiation'.  All I've found is that a hidden 'user' CGI like program
can provide the logic and send the right data.... Either the server(s)
are or will be smart enough to understand how to recogize many 
document types to send in response to requests or installation code
will provide the logic or both, but in any event it doesn't seem
like a far leap for the same servers to know enough about the content
formats to be able to obtain the shape.  It also seems reasonable for
the provider of the IMAGE (not the referencing HTML or whatever) to 
provide meta information in a standard form for servers.  Shape
parameters should relate to the data type.  Images suggest size, 
video might add frames or time as a metric, etc.  An acceptable
response from a server must be "can't figure it out", etc.

Down the road, it might be helpful if the HTML files had optional
size metrics.  I would hope at some point that an acceptable 'image'
format would be nested HTML and it would certainly help in that case.
I know shape/size leaves a lot to the rendering processor, but it 
might help to know a length in some standard measure given a specified
width and font size assumptions...

Dave Morris

Received on Wednesday, 21 December 1994 23:32:56 UTC