[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