Re: Toward Closure on HTML

lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)

Mail folder: WWW Talk Apr 94-present
Next message: Daniel W. Connolly: "Come 'n Get it: A DTD for current practice in HTML"
Previous message: Omy Ronquillo: "Converter: MAN to FRAME."
Maybe in reply to: Rob Earhart: "Re: Toward Closure on HTML"
Reply: Bryan Oakley: "Re: Toward Closure on HTML"

Errors-To: listmaster@www0.cern.ch
Date: Thu, 7 Apr 1994 01:14:14 --100
Message-id: <94040700111962@cguv5.cgu.mcc.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Toward Closure on HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2641

earhart+@CMU.EDUsaid 
> I said:

>> Case 1: client has inline images ON and supports multipart messages, server 
>> is  multipart aware  

> What if the server already happens to have some of the images cached?
> It seems like a waste to be constantly retransmitting the images.

True. But transmitting to the server what images it has cached incas eany of 
those are in the current document seems too big an o verhead. As I said, from 
the users point of view the delay is in establishing each connectiuon. 
Retransmitting inline images seems better, IMHO I agree this is a flaw with the 
suggested method, though.



>> Case 2: client has inline images OFF and supports multipart messages, server 
>> is  multipart aware

>  Presumably with links of some sort, so that the images could be
> fetched later

Of course ... as I said, blah.html is transmitted as the current situation, so 
the links are still in there. Presumably the browser wouls put small icons for 
delayed image in those places where the inline images were not in the browser 
cache, as at present.

>   I still think that the current scheme of embedding URL's to images in
> lieu of the images is a good one.

I agree, and did not suggest otherwise in my original post. The idea is not to 
remove the URLs or change the html in any way, but to predict that the browser 
will ask for a bunch of inline images shortly, and send them all in a bunch.

> Granted, the need to reconnect for
> every image is annoying; it would be "nice" to be able to send multiple
> requests per connection to servers that didn't immediately close down...

Well that is the other way of doing it, and would also account for cached 
images. Let the *browser* do the parsing, as at present; build up a list of 
inline images not in the cache, then send this as a list of GETs in one request. 
This would need more changes to the HTTP spec, though, I suspect.

Chris Lilley
+-----------------------------------------------------------------------------+
| Technical Author, ITTI Computer Graphics and Visualisation Training Project |
+-----------------------------------------------------------------------------+
| Computer Graphics Unit,        |  Internet: C.C.Lilley@mcc.ac.uk            |
| Manchester Computing Centre,   |     Janet: C.C.Lilley@uk.ac.mcc            |
| Oxford Road,                   |     Voice: +44 61 275 6045                 |
| Manchester, UK.  M13 9PL       |       Fax: +44 61 275 6040                 |
| <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">click here</A> | 
+-----------------------------------------------------------------------------+