Re: HTML+ Addition

Tony Sanders <sanders@bsdi.com>
Errors-To: sanders@bsdi.com
Errors-To: sanders@bsdi.com
Message-id: <9310041453.AA01241@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML+ Addition 
In-Reply-To: Your message of Sun, 03 Oct 93 19:11:54 BST.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 04 Oct 1993 09:52:59 -0500
From: Tony Sanders <sanders@bsdi.com>
> How about making the document a "multipart/hyper" (well, ../x-hyper for now)
> type, where the first part (of type "text/html") is the initial text, and
> contains links to the later parts (e.g., of type "image/gif" suitably encoded)?
This blows any caching scheme you might have out of the water (not an
issue if you are talking news distribution but it is a *BIG* issue when
you are talking interactive performance), but if you are going to bundle
then I do agree we should use a MIME type (though I think multipart/mixed
is probably suitable and it's already well defined).  You can also use
multipart/alternative for sending different representations of the same data.

> Then there'll just be the one document fetch; it will automatically work for 
> news:
Dan Connolly wrote a bunch of stuff about this back in June 1992.  Check
out the www-talk archives (get the 1992 stuff):
    http://info.cern.ch/hypertext/WWW/Administration/Mailing/Overview.html

> it'll be easier to do servers which generate inlined images on-the-fly,
> and more.
I think you have this backwards.  It's a hell of a lot more work on the
server end.  How do you decide which images to include?  Are you going
to parse the HTML on the server end?  What happens with:
    <IMG SRC="http:otherserver...">
There are lots of other issues to be considered here.

--sanders