[PEAK] peak.naming question

[Phillip J. Eby]

At 11:24 PM 12/21/04 -0500, Andy Gross wrote:

>I'm really liking peak.naming so far.  I've been subclassing from 
>GenericPathURL and registering in peak.naming.schemes, which has allowed 
>me to toss out a bunch of bug-ridden legacy config parsing code.
>
>I'm at a point where I can get rid of a bunch of subclasses that only 
>differ in their getObjectInstance implementation.  Each naming scheme 
>allows for abbreviations in the "host" portion of the URL.  In the example 
>URL "someproto://foo", "foo" references a set of configuration properties 
>protocols.someproto.servers,

This is a bit off topic, but in general, '//' in a URL is intended to 
designate a naming *authority*, rather than a name.  There are some PEAK 
URLs that allow a '//' for something that is not an authority, but these 
date from before Ty and I understood the name vs. authority 
distinction.  In general, the URL RFC's do not recommend using '//' when 
you are not beginning something with a hostname, or some other "universal" 
naming scheme (like LDAP OIDs).  For this reason, I would suggest that 
'someproto:foo' would be better syntax for a use case like this.


>  and getObjectInstance (by default) should return a random choice out of 
> that set.  I've pasted some example code below to illustrate.
>
>I'd like to implement the server-picking functionality in some place other 
>than the actual object who's class implements getObjectInstance - I'm just 
>not sure if it should be done in the URL subclass, or if I should need to 
>make a context subclass for the resolution process.  I suppose there are a 
>number of ways to implement this, but I'm curious as to the 
>idiomatic/proper way to do it.

Note that an object factory does not have to be the same class as the URL, 
and that more than one factory can be used with a URL.

naming.Reference() (and the 'ref:' URL scheme) can be used to designate a 
specific object factory to be used with a given address.

So, for example, 'naming.Reference("somemodule.someclass", 
["irc://xyz.foo.bar", "irc://abc.foo.bar"])' denotes the use of the 
'somemodule.someclass' object factory with the two given addresses, and if 
you look it up, you'll get the result of 
somemodule.someclass.getObjectInstance(), called with the reference object 
as the refInfo parameter.  You could also denote the same reference with a 
URL like this:

      ref:somemodule.someclass at irc://xyz.foo.bar||irc://abc.foo.bar


Now, the "idiomatic/proper" way to do this is that you simply use a naming 
context that looks up a name like "foo", and returns a Reference.  You then 
have the object factory do any selection between addresses, or fallbacks, etc.

The idea here is that a *name* (like "foo") is translated by a naming 
service to a *reference* which designates a *factory* and one or more 
*addresses*.  Addresses (URL schemes) are supposed to be reusable for a 
variety of purposes.  So, even though there is a default factory associated 
with URL schemes, you do not subclass the URL scheme just to get a 
different factory.  Instead, just create a reference to bind the desired 
factory to the appropriate addresses.  Then, so that code doesn't need to 
know the details, just use the configuration system or a name-based context 
to map from a symbolic name (like "foo") to the reference.

Does that make sense?