Unfortunately, I'm not familiar with AppConfig... I'm dealing with generic initialization/configuration modules here.

LookupFactory is a factory for Lookup::* objects. It has an initialization parameter file (i.e. a config file) that has the parameters of how to instatiate different types of Lookup:: objects.

Your initialization class runs at the start of your service, preparing for the first request. It starts up LookupFactory which receives the parameters that are appropriate to individual Lookup::* modules (e.g. RemoteURI).

When the user->source() method is called, it requests (from UserSource) a source that is applicable to user. Based upon a separate config file (or a separate section of the same config file, if you so choose), it reads the appropriate user source for this app is "Lookup::Remote" (or more abstractly, just "Remote" or some such moniker).

UserSource can request the item from LookupFactory which will instantiate a Lookup::Remote object (or whatever Lookup object is requested) if one is not already available in the "pool" of Lookup Objects. When the LookupFactory instantiates the Lookup::Remote object, it already has knowledge of the aforementioned RemoteURI from it's config file.

This is my experience in a (granted, Java-based) production-environment application. It provided great separation of knowledge and sub-classes of generic objects from the business logic. Some see this as overkill, but I found it to be highly maintainable and separable. Please let me know if you have any more questions or if this is not clear. It is based upon the Avalon framework.