The $RemoteURI parameter tells Lookup::Remote which URI to request user information from, given a user-id. It performs this request via LWP. The User class encapsulates information concerning a user (surprise!).

To avoid heavy network traffic, user data is cached locally for a time, so when $user->info is requested, the user code first tries Lookup::Local to determine if information is cached locally, and if not then uses Lookup::Remote (I realise these are less than perfect names, but they suffice).

It's actually not separated out like that (there is just one Lookup class to perform the actual information collection), but for the purposes of discussion it might help to know that there are potentially two steps to determine user information.

The $RemoteURI doesn't relate at all to the User, it is just where information will be pulled from - it's configurable, because one installation of the code may be configured to query server A, while another is configured for server B; and it's a class variable because all instances of the class have to hit the same server, and it seems wasteful to store this per-instance. The nature of this product means that round-robin DNS or other centralised user management is not an option.

Some very simplified sample code is shown below, with questionable bits commented.

use User;

my $config = AppConfig->new;
$config->define(
  remote_uri => { DEFAULT => '', ARGCOUNT => ARGCOUNT_ONE }
);
# config file sets remote_uri;
$config->file('/path/to/conf');

### I'm trying to avoid having to do this.
use Lookup::Remote;
Lookup::Remote->remote_uri($config->remote_uri);
#######

# Set user data from cache or remote as available.
my $user = User->new(id => '1234')->init(); 

# Do stuff with $user..
[download]