The Naming of Names

Essentially everything proposed in this document has been completed at this point; it is now primarily of historical significance.

Agents

Agency -> Admin, Agency/ROOT -> ROOT

Completed 1999-02-09.

It has been pointed out that our use of Agency is ambiguous. We need to change it; Admin has been proposed. There is also a problem in that the Agency agent is really doing four things:

1. Administration. Clearly Admin
2. Handling the root pages. Pretty clearly a new agent called Default, PIA, or ROOT.
3. Serving default icons, and so on. ROOT/Icon. An alternative would be a separate Icon agent; putting it under ROOT means that it doesn't show up on agent listings.
4. Handling requests directed at agents (in its actOn method). Possibly this should be done in the Resolver, or possibly in ROOT.

Both ROOT and Admin could be constructed by copying the code for Agency.

ROOT seems to be preferred at the moment. Note that it ought to be possible to register the default (root) agent. Note that an appliance's main agent might typically do so.

Spy -> Toolbar

Completed 1999-02-04.

... or possibly Tools. cia and fbi would become remoteTools and localTools respectively.

With Toolbar as the main agent, cia became remote and fbi became localFile, documented as applying only to local (passive) files and not active pages.

PIA/Doc, etc.

ROOT should handle these. It might actually have a suitable actOn method in XHTML.

It seems possible that the only differences between a DOFS agent and a regular one might end up being:

1. how you get to the agent's control pages.
2. how it maps file extensions into mime types, and which ones are active (and with which tagsets). This could be done with a namespace.

Under this scheme, an agent would have both a ``home'' directory and a ``root'' directory, and also both a ``home'' and a ``root'' tagset.

Mapping Agent URL's to Directories

Currently:

The following URL's refer to an agent's directories:

URL	Directory	description
/name	pia/Agents/name	an agent's ``root'' directory; normally the same as its ``home'' directory unless it's a DOFS agent
/type/name	pia/Agents/type/name	an agent's home directory if type is not the same as name
/~name	.pia/name	an agent's data directory
/My/Agents/name	.pia/Agents/name	an agent's user directory, containing the overrides for the files in the agent's home directory.
/My	.pia	DOFS agent referring to the root of the data directories
URL	mapped to:	description
/path	/Agency/ROOT/name	a file ``in the root'', handled by Agency
/badfile		missing root file, handled by Agency
/bad/path		missing agent, handled by the Resolver.

Proposed:

Completed 1999-02-09.

For the moment, /type/name is still working.

The only really drastic changes here are:

1. Going from /type/name to name~ to designate the ``home'' directory. It will simplify the lookup considerably.
2. Changing from /My/ to /~/. It has to be treated specially because /~~ seems ambiguous -- is it home or data? It is better to regard /~ as simply an alias for ~ROOT -- the root agent's data directory. This neatly sidesteps the need for a separate DOFS agent for it.

An alternative scheme would be to changing the meaning of ~ from ``data home'' to ``code home'', and consistently use /~/ as the root of the data directories. This is a little more consistent with Unix usage, and would remove the ambiguity about the meaning of /~~, but represents a significantly larger change.

Another way of looking at an agent's ``root'' directory is that it might be either its home or its data directory. Hence, for a DOFS agent, the root is the data directory, not the home.

Ideally, a missing file should be handled by mapping it to a URL in the ROOT agent. This will require the ability of DPS code to set the HTTP result code, which is not possible yet.

``Mounting'':

Completed 1999-03-23.

For the moment, /type/name is still working.

It would be desirable to ``mount'' agents anywhere in the agent tree. A ``mounted'' agent would have the following URL's:

URL	Directory	description
/path/name	pia/Agents/path/name	root directory
/path/name~	pia/Agents/path/name	home directory
/~/path/name /path/name/~	.pia/path/name	data directory
/~/path/name~	.pia/Agents/path/name	user directory

Agents need the following attributes:

name

the base name

type

An agent from which forms are inherited.

path

An agent's mount point in the URL hierarchy. The path from the ``base'' (PIA/Agents or ~/Agents) to the agent's code or user directory is normally equal to path/name; it is probably not necessary to permit the directory and URL paths to differ.

home-dir

the full path to the code directory. Specifies only the agent's code directory, not the user directory.

user-dir

the path to the user directory. Probably very rarely used.

data-dir

the path to the data directory.

In specifying paths, we should allow the following prefixes:

~/

The user's home directory (currently the only one allowed)

./

(or any relative path) the PIA agent directory

../

the PIA home directory &PIA:dir;, as in ../Contrib/...

/~/

The PIA root directory &PIA:root;

Currently, an agent's ``name'' has to be unique. Under this scheme, it only has to be unique with the path prefix. This changes findDocument somewhat.

Considerable effort will be involved in this change, because presently the name is used as the key for the agent table.

Tagsets

1. Several tagsets can share a namespace. For example, dps: is shared by basic, xhtml, and xxml.
2. The name is usually derived from the DTD name, which in turn is supposed to be derived from the tag of the top element.
3. A tagset like pia-xhtml should have a name of xhtml (the DTD from which it is derived) and a prefix (namespace) of pia:.