Re: good practice for clients

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Neil,

>   .  It should be possible to configure logs and feedback to the user either
> 	to maintain transparency or to enable debugging.

The two are not mutually exclusive, as you imply by "either ... or". Feedback 
related to data content or source (i.e. the URL) is conceptually distinct from 
that describing the server from which data was pulled. It's definitely the 
case now; URNs will make it completely so. Maybe...

   .  It should be possible to configure logs and feedback to the user
 	to display any combination of details, including at least (a) which URLs
        are being requested, and (b) which servers were used to satisfy the 
requests
        and whether the request directly or by proxy.

> The current lack of any kind of `HTTP traceroute' is occasionally a
> problem.  However proxies are, in the general case, expected to operate
> transparently, and it may be positively confusing/alarming to be told
> that you are connecting to www.foo.bar when you have never even heard
> of www.foo.bar.

It is an unfortunate fact that when systems are essentially complex, end-users 
want them not to be. So, naturally, there are multiple levels of detail for 
feedback, corresponding to the requirements of different types of user. No 
argument there, I take it. However, I have never, ever come across a case 
where providing *wrong* information is better than providing none, or where an 
end-user, if asked, wants anything other than either the *correct* information 
or to just not be bothered about it.

Frankly, if I were such a user (and I *am* a naive user of other people's 
complex systems), I feel insulted when it becomes clear that I am considered 
too thick to cope with what's going on. Ever tried to apply common sense to 
the arcane procedures of a bank by asking the counter staff who are supposed 
to "know" all about what goes on? You won't get very far, because they are 
programmed to provide a simplistic image of the whole complex process, which 
is frequently incorrect. Not just incomplete, incorrect. Let's be better than 
banks.

> I think the Netscape behaviour is correct. As long as the browser hasn't
> connected to the proxy yet it indicates a connection to the proxy, once
> that connection has been established it starts talking in terms of the
> remote server. If your proxy is down, it's immediately apparent.

I really do not see how you can defend this. Netscape is wrong: a connection 
is a connection; in terms of the socket interface it uses connect(2). If it's 
not a connection, then don't call it a connection. If you aren't connecting to 
a host, don't say you are.

By all means say something like "Obtaining http://www.foo.bar/home.html", but 
if the user is going to be confused by the idea of a proxy, then why give him 
a status message at all? The only other reasons for feedback which occur to me 
are (1) reassurance that something is happening - that's what the meteor storm 
and "thermometer" are for or (2) so that the end user can pass the message 
back to a guru; in which case the text of the message must read correctly, 
because the guru needs to know whether a proxy is involved. Even if the 
end-user has a hazy concept of what connection means, gurus know exactly.

In my experience, users are good at noticing correct behaviour; if they're 
taking notice at all, they quickly see that, when the system is working 
correctly with a proxy, the status message says that the connection is to a 
local proxy. That wouldn't be confusing or alarming, that would simply be how 
it is. It *is* confusing and alarming to be suddenly told that, when one has 
been under the impression that Netscape was making a direct connection, in 
fact it wasn't. It certainly wouldn't improve my faith in any other status 
messages.

Furthermore, I disagree that "If your proxy is down, it's immediately 
apparent". It may be apparent to you and I, Neil, but it's only apparent to an 
end-user IF HE IS AWARE THAT HE IS USING A PROXY. If he isn't (because 
Netscape has been lying to him), then it just looks like a network outage, all 
the more so if the local server has been explicitly excluded from the default 
proxy configuration (misconfigured proxy set-ups have been reported to me as 
"JANET is down"). It is *precisely* at the point of a failure (which can be 
more subtle than just an outage) that one needs all the relevant facts, 
CORRECTLY stated. Anything else just wastes time and resources.

Peter Lister                             Email: p.lister@cranfield.ac.uk
Computer Centre, Cranfield University    Voice: +44 1234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK        Fax: +44 1234 751814
 --- Unfortunately, science isn't about happiness; it's about truth ---



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBMcWGoE0IjEzZ62ARAQGFTQQAgTtS9DLAImZ5PGDNRMtGJCj230CxeIS8
zWmKPLyMYQi17x8Euz0Jwaox8lmQ5nw0rVL6eR86vRlvzvUYvRu9QuXzU7BGNyeM
sZQH5jyVKTpIWfpEKKZInDDmZ05IBMPzJqkOIiVBTxkCokqQZBLy0flcBOuxzTeq
+jHQU2vW1Yo=
=Iupj
-----END PGP SIGNATURE-----

Received on Monday, 17 June 1996 12:24:16 UTC