Re: Auto-Download tags/function?

Tony Sanders <sanders@BSDI.COM>
Date: Thu, 19 May 1994 23:14:01 +0200
Message-id: <199405192109.QAA02225@austin.BSDI.COM>
Reply-To: sanders@BSDI.COM
Precedence: bulk
From: Tony Sanders <sanders@BSDI.COM>
To: Multiple recipients of list <>
Subject: Re: Auto-Download tags/function? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Organization: Berkeley Software Design, Inc.
Organization: Berkeley Software Design, Inc.
"Daniel W. Connolly" writes [on URI:]:
> Nope. This is sufficient. It's nearly equivalent: it's just a question
> of what's explicit where vs. what's implicit where.
Well, it still doesn't solve the proxy problem for the general case where
the link is to a varient URI where there is still no way for the proxy to
know that a document in the cache is the proper match.  Of course, you
can use heuristics for the general case and use ``Pragma: no-cache'' when
you need it done right.  I would still like someone to think about this
some more.

It also doesn't address some other points you made in another
posting, like testing for error conditions and user interface.
But content-type in the URL doesn't really solve those either.

> does address some of my concerns. I'll have to meditate on it a while
> to see if it solves the whole problem I'm interested in.
Yes, cogitate on that for a while and see what you come up with.
Don't forget that you need to consider image depth, resolution,
colomap, and a million other details when asking for "the same thing".

I don't see how you can do exactly what you want to do in a reasonable
enough way that it will ever be supported.  There are some good things
to think about in there though.

> Hmmm... it seems that putting type info in the link is still
> useful for FTP, though.
Yes, we've covered that.  There was never any doubt in my mind.
The current FTP URL space has a number of problems.