Please write "Using MIME multipart/* syntax is not a very good
solution..."
MIME multipart/* syntax is designed for use in Internet Mail and
USENET news, where a reliable bytestream is not guaranteed.
In the context of HTTP, something like application/tar (or
application/bento) would be more appropriate. Consider:
User selects the following anchor:
<p>For complete details, see
<cite><A HREF="http://host.com/reports/r100.tar#top.html">
Report 100
</A></cite>
Client connects to host.com and tells the server it prefers
text/html, image/gif, and application/tar, but it will take
postscript, tiff, and multipart/mixed:
GET /reports/r100.tar HTTP/1.0
Accept: text/plain; q=0.7, text/html; q=1.0
Accept: image/gif; q=1.0, image/x-tiff; q=0.7
Accept: application/postscript; q=0.8
Accept: application/tar; q=1.0, multipart/mixed; q=0.9
Server looks for /reports/r100.tar in its filesystem, but doesn't
find it. It does, however, find a directory called /reports/r100,
and it knows how to convert a directory to a tar file. It may write
the tar file to disk and cache it (and hence be able to tell the
client the Content-Length before hand), or it may just pipe the tar
output right over the wire. (NOTE: the server must check that all
the constituents are Accept:able to the client)
200 document follows
Content-Type: application/tar
Content-Length: 81920
...tar file...
Client receives the tar file, and either stores it in memory or
writes it to local disk (probably broken into constituent files). It
knows that fragment identifiers in application/tar entities refer to
the contituent files. So it resolves #top.html and displays
top.html. _AND_ it can resolve relative links from top.html to the
other parts of the tar archive. So all the <image SRC="xxx.gif">
files get displayed without any more HTTP transactions.
The only part of the architecture that needs to change is that this
strategy requires that the decision of whether to send just the
.html node or to send the whole collection of files is made by the
author of the link when s/he writes:
HREF=http://host.com/reports/r100.tar#top.html"
... and that decision should probably be negociated between the
client and the server based on file sizes, user preferences such as
"delay image loading", etc.
I would argue that the long-term solution is richer linking markup.
But I don't have the whole argument put together just yet...
MIME, Mosaic, and WWWLibrary
------------------------------
Does anybody else think it's funky that Mosaic treats message/rfc822
body parts three different ways?
* If you give a file: reference to a file ending in .mime, it launches
metamail
* If you give a news: reference, it formats the headers as HTML,
and displays the body as plain text (no matter what the content-type
is)
* If the message is an HTTP response, it hides the headers (even the
interesting ones like Last-Modified:) and displays the body
according to the content-type.
Why are these three cases not handled the same way? (or very nearly
the same... message/http should probably have slightly different
semantics from message/rfc822)
And what the heck is "www/mime"? The name refers to the same thing
that is called message/rfc822 in MIME parlance.
Dan