Re: Toward Closure on HTML

• Mail folder: WWW Talk Apr 94-present
• Next message: Omy Ronquillo: "Converter: MAN to FRAME."
• Previous message: Chris Lilley, Computer Graphics Unit: "Re: Toward Closure on HTML "
• Maybe in reply to: Piglet: "Re: Toward Closure on HTML"
• Reply: Chris Lilley, Computer Graphics Unit: "Re: Toward Closure on HTML"

Errors-To: listmaster@www0.cern.ch
Date: Wed, 6 Apr 1994 23:38:05 --100
Message-id: <whcmfeO00WC70IHvtD@andrew.cmu.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: earhart+@CMU.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Rob Earhart <earhart+@CMU.EDU>
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
Organization: cmu
Organization: cmu
Content-Length: 1166

  Sounds interesting... I just have two comments.

lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit) writes:
> Case 1: client has inline images ON and supports multipart messages, server is 
> multipart aware
> Server bundles up blah.html and all its inline images as a MIME multipart, ships 
> it all over the net in one go, client unpacks it and does the right things with 
> the bits.

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

> Case 2: client has inline images OFF and supports multipart messages, server is 
> multipart aware
> 
> Server sends blah.html as current situation

  Presumably with links of some sort, so that the images could be
fetched later. (heh.  Using 'message/external-body' as a base, define
content-type 'image/external-body'... :-)

  I still think that the current scheme of embedding URL's to images in
lieu of the images is a good one.  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...

  )Rob