Comment 2 for bug 570545

The general issue behind is that HPLIP should be
better prepared to deal with the case when the
current actual CUPS server is a remote machine.

There are various ways for a user to define the current actual
CUPS server, e.g. the admin can set a ServerName entry
in /etc/cups/client.conf but any normal user can set a different
CUPS server in his ~/.cups/client.conf file, see
http://www.cups.org/documentation.php/doc-1.4/ref-client-conf.html
or the environment variable CUPS_SERVER
is set to whatever else server.

An environment variable CUPS_SERVER overwrites
a ServerName entry in ~/.cups/client.conf and this
overwrites a ServerName entry in /etc/cups/client.conf

Since CUPS 1.4 there is the new 'lpstat -H' option which shows
the current actual CUPS server regardless how the user had
defined it.

If 'lpstat -H -r' does not show
something like
--------------------------------
/var/run/cups/cups.sock
scheduler is running
--------------------------------
or
--------------------------------
localhost:631
scheduler is running
--------------------------------
or something like
--------------------------------
LocalHost:631
scheduler is running
--------------------------------
or
--------------------------------
127.0.0.1:631
scheduler is running
--------------------------------
or something like
--------------------------------
127.000.000.001:631
scheduler is running
--------------------------------
then the current actual CUPS server is a remote machine.

In this case HPLIP should behave accordingly - i.e.:
Show a meaningful warning message that some functionality
does not work via a remote CUPS server and fall back
to the functionality which is still possible with a remote
CUPS server (e.g. only plain printing and show only
the remote print queue state but do no longer provide
an actual remote USB device status).