From: stripes@uunet.uu.net (Josh Osborne)
Message-Id: <9403212209.AA29383@rodan.UU.NET>
Subject: Re: Reliable links [Was: Stab in the dark ]
To: connolly@hal.com (Daniel W. Connolly)
Date: Mon, 21 Mar 1994 17:09:52 -0500 (EST)
In-Reply-To: <9403211836.AA12832@ulua.hal.com> from "Daniel W. Connolly" at Mar 21, 94 12:36:09 pm
[...]
>I did not suggest that. Please read carefully. I took the trouble to
>construct a concrete example motivating the OPTION to specify a
>specific sequence of octets as the referent of my citation.
I'm sorry, either I missed it, or you didn't make it clear.
[...]
>I agree. I wrote:
>>>For the content-type dimension, the format negociation algorithm in
>>>HTTP works pretty well...
>
>Now, back to my scenario: what about FTP?
Broken as designed?
>>Also http://foo.com/dr.fun/most_recent.jpg, should not be constained to
>>pointing at one image, it should be free to change from day to day.
>
>What if I have a complaint about tuesday's version which is fixed in
>wednesday's version, and then somebody reads my complaint on thursday?
Tell me, how do you fix a cartoon :-)
>Then I look silly, cuz it's not apparent to the thursaday reader that
>my complaint was once valid. Consider online document reviews,
>contract negociations, most other CSCW applications...
If you complain about someting, you should include the parts you are
complaining about. If you are doing online document reviews you should
refer to a version, whether it's implicit in the URL, or explicitly outside
(the 4:50 21Mar94 version of foo...).
>>If you want to cache at the application level, you can assume whatever
>>object you fetched last is still valid, unless the user changed some
>>defualt or other that might effect things ('color/monochrome'). You
>>should also timeout data when it expires (if the protocall has a TTL or
>>expire date like HTTP), or after some fixed length of time (a few hours).
>>If you are doing caching _outside_ the application (like a gateway) you
>>need to understand enough of the protocall being used to figure out what
>>version of the bits is being fetched, and either handle it from the cache,
>>or fetch it from the real source.
>
>So much for scalable distributed systems... if I've got my own caching
>strategy, and you've got yours, and we don't agree on how to encode
>meta-information, then we can't share cache namespaces.
For http:
How about we try to cache within the system before we "fix" it?
I think you *can* make a caching http server without making URL's
nail down the type, version, and whatever else can vary about a
document. The cache server needs to remember what version of the document
it was offered, what ones it has, and when they expire (all outside of
the URL), and will either return the version it has cached, or pass the
request through (filling it's cache in the process).
>fI really disagree fundamentally with the notion that every resource
>has a "home" and you must make a round-trip to that home to access the
>resource in any well-defined way. This means that caches are all
>heuristic optimizations, doomed to failure in unanticipated cases
>(since all the cases aren't specified.)
I also dissagree with that notion, however only HTTP (and perhapse gopher+),
and news can allow retreval without talking to the "home server" (HTTP
explicitly defines a expire date for a bit pattern, news won't re-use
a message-id for years (4?), and I don't know how gopher+ works).
For systems without a expite-date, or TTL caching is a heuristic process
doomed to failure in unanticipated cases, much like type, or version
determination in protocalls that don't support them are also heuristic
optimizations, doomed to failure in unanticipated cases.
We can define conventions, or even a standard for each URL (to determine
type, version, and TTL), but that will either break existing URL's, or not
be a requirement, and therefore not be followed in all cases...
-- Not speaking for UUNET Technologies
