[TransWarp] Names vs. Addresses

Phillip J. Eby pje at telecommunity.com
Wed Jun 11 17:57:03 EDT 2003


This is just an attempt to clarify an aspect of peak.naming...

Something is a *name* if you could potentially bind (i.e. store) different 
objects in that location.  It is an *address* if the location *is* the object.

For example, if I refer to 'shlockfile:/var/run/foo.lock', there is only 
one object that that could ever refer to.  It's the shlock file, 
/var/run/foo.lock.  I can't "put" something there, that *is* the something.

Another example, 'import:' refers to a Python object via an 
import/getattr() path.  I *could* replace the subject of that import with 
some other object, so technically 'import:' URLs are names.

DDE and SMTP connections, and even most database connections are 
addresses.  What would you "put" at such a location as a SMTP 
address?  E-mail?  No...  because you can't get it back out.  SMTP is just 
a place to dump something.  In general, services that you "connect to", but 
that don't provide a namespace to "put" things in, are addresses.

In general, names should be managed by a *naming context*.  A context is an 
mapping-like object that can look up names, and possibly save objects under 
a given name.  In this sense, it's meaningful to think of file-like URLs 
(e.g. http:, file:, ftp:, etc.) as names, because one could create a naming 
context to work with them.

These are not hard-and-fast distinctions.  In principle, we could say that 
a DB server is a namespace that contains databases, and that you should be 
able to "put" a database in it, or list the databases in that 
namespace.  That's perfectly valid reasoning, for some database types.

Also, many URL schemes in general are namespaces, but can also describe 
queries.  LDAP and HTTP are both like this.  An LDAP or HTTP URL with a 
query in it is clearly an address, but ones without queries are names.

Most schemes currently implemented for PEAK are treated as addresses.  This 
is because it's much easier to implement an address than a context, and you 
have to create the address type before you can create the context 
anyway.  I do intend to have contexts implemented for all "name" schemes 
eventually, but it's been waiting on other infrastructure improvements in 
PEAK.  For example, I needed to get the file-like address schemes set up 
before I could do any contexts based on them.  Also, I don't have need of 
many of the contexts yet, although I can foresee wanting to have some of 
them later.

There are also some address schemes that are fundamentally weird.  :)  Our 
logfile and zconfig.schema URL schemes are good examples of this.  They 
name an object that lives in a namespace that *can* be rebound, in the 
sense that I could change the file that's there.  They exist only to 
provide context on another URL, effectively "adapting" that URL to another 
kind of object.  In principle, this is redundant -- we could just as easily 
adapt a 'file:' URL to an ILogger.  One generally doesn't bind without 
knowing what interface one wants to bind to.  For other uses, it's not as 
clear-cut, if there is more than one possible *kind* of 'file:' ILogger.

But, the natural fit for this type of thing seems to me to be ZConfig, or 
else a *real* naming system.  In other words, ZConfig already supports 
matching a binding to an interface (via sectiontype and 
abstractsectiontype), so why make the user learn a URL syntax instead of 
just writing ZConfig sections to define the actual object?

For applications that ZConfig doesn't work as well for, the correct 
approach is probably to use a "real" naming system.  That is, one that 
supports storing objects.  I'm beginning now to see the usefulness of 
JNDI's "Reference" objects, which basically store the name of a Java class, 
and a list of addresses.  I think I'm going to have to go back and look at 
JNDI again to decide what to do about this.  I really want to keep it 
possible to use plain text to refer to these things, but I also don't want 
to have an enormous proliferation of URL schemes in order to refer to every 
possible object type either.  And the list seems to keep getting 
longer.  Further, if you've already written an object type, why should you 
have to also create an address type for it?





More information about the PEAK mailing list