Re: image/*, audio/*, etc.?
"Marc Andreessen" <marca@ncsa.uiuc.edu>
X-Delivered: at request of secret on dxcern.cern.ch
From: "Marc Andreessen" <marca@ncsa.uiuc.edu>
Message-id: <9310070428.ZM4267@wintermute.ncsa.uiuc.edu>
Date: Thu, 7 Oct 1993 04:28:05 -0700
In-Reply-To: Nick Williams <njw@cs.city.ac.uk>
"Re: image/*, audio/*, etc.?" (Oct 7, 10:17am)
References: <9310060413.AA13316@wintermute.ncsa.uiuc.edu>
<cggxuG2__5g94S=GJ9@cs.city.ac.uk>
X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail)
To: Nick Williams <njw@cs.city.ac.uk>, www-talk@nxoc01.cern.ch
Subject: Re: image/*, audio/*, etc.?
Cc: webmaster@cs.city.ac.uk
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
On Oct 7, 10:17am, Nick Williams wrote:
> > So... does anyone object to image/*, etc.? (Precedent is in the
> > mailcap RFC, btw.)
>
> I definitely object. I think it is unreasonable from the viewpoints of
> both being a server maintainer and a user.
> Consider the case where a document contains:
> <img src="blah/blah/blah/foo">
> And the server which "owns" foo has it stored in format
> usenix-facesaver. When Mosaic makes the request for the image, and asks
> for type "image/*", the server will respond with the easiest to produce
> version: i.e. the native usenix facesaver picture. Mosaic doesn't
> understand this, but carries on anyway. Perhaps the link is slow as
> well, causing the download of the picture to take a long time. Finally,
> the picture arrives. Mosaic doesn't understand the return type (even
> though it asked for it) and so will not include it in the document, but
> forks off xv instead. And although the chances of xv understanding it
> are high, it is no certainty either.
>
> The alternative:
> Mosaic asks for "image/gif, image/xpm, image/xbm" (it's an inline, so
> mosaic shouldn't be speaking for xv just yet). The server doesn't have
> the image in that format so either:
> 1) it converts it to the correct format and so the reader of the
> document gets exactly the correct view.
> 2) it responds that it is unable to provide the image in that format and
> Mosaic can immediately work around this (as opposed to waiting for all
> of the image to be downloaded).
I understand the alternative. The problem is that we've decided to go with MIME
in the protocol; mailcaps are how MIME is traditionally supported in clients; if
we don't allow image/* etc. we do not do true mailcaps and we lose compatibility
and compliance with the MIME/email world, one of the reasons we used MIME in the
first place.
You are correct about the problems with image/*. However, as a server
maintainer, you shouldn't need to care. If a client doesn't think it can handle
any form of image, it shouldn't ask for image/*. If it *does* -- and keep in
mind that I may have an external image 'viewer' that is perfectly capable of
saving formats it doesn't understand to disk rather than just puking, so I as a
user can go get a suitable viewer at my convenience (*if, as a user, I wish*) --
then the server should just say "Well, OK, here ya go."
As a result of the problems that have arisen with pre4, btw, I'm going to not
use any wildcards in the default Mosaic mailcap stuff -- image types will be
elaborated, etc. and so wildcards will never come into play unless someone
specifically wants them to -- however, I am arguing in favor of (a) compliance
with the spec and the rest of the world [which I think is a Big Deal] and (b)
allowing users to do what they want on the user/client end.
> There. Purely from the view of a server maintainer: I put in a lot of
> working getting our server to do conversions automatically! :-)
>
> Repost this to the list if you want a discussion; I thought I'd just
> send to you because the noise in www.talk is too much right now :(
Cheers,
Marc