Re: Transparency vs. Performance: survey of opinion

I agree with Shel -- and I think his statement is not inconsistent with 
Jeffs' and reflects what I heard at the caching subgroup meeting.

I'd summarize my take on the essential item as:  the server should 
provide information to proxies and clients, on each response, on the 
relative desirability of trading off transparency for performance for 
the resource contained in that response.

There are cases where the server knows for sure that  if the client or proxy
ignores the servers advice, then the user's view of the web-based 
application will be that it is broken.  One of the things  that causes 
"clients that don't work well with servers, as far as users are 
concerned, [to] not survive in the marketplace" is if you can point out 
that the client ignored information sent in compliance with the HTTP 
protocol defined.  In turn, it is necessary for what the HTTP protocol 
defines to be flexible enough that servers don't have to ask for too 
many performance sacrifices in order to get the behavior they need.  As 
it is now, clients want to ignore "no-cache" because servers demand it 
even when weaker behavior would do (but isn't defined in HTTP).

Paul
----------
] From: Larry Masinter  <masinter@parc.xerox.com>
] To:  <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
] Subject: Re: Transparency vs. Performance: survey of opinion
] Date: Monday, February 26, 1996 2:21PM
]
] There's been additional discussion on the topic, but not a lot of the
] kinds of notes that make it sound like 'consensus'. Could folks please
] briefly let me know where you stand, e.g., "Agree with Roy", "Agree
] with Shel", "Agree with Jeff", or "Have a different opinion" or
] something equally short.
]
] For example, I can't tell from Carlos Horowicz' note
] <199602261411.OAA15343@patora.mrec.ar> whether he fundamentally agrees
] with Shel or thinks that the changes he proposes are essential.
]
] I'm not trying to cut off discussion, I'm just asking people to
] summarize their fundamental stance.
]

Received on Monday, 26 February 1996 19:04:47 UTC