User Agents are objects which wrap URLs which are known as the "location" or the "context." They fetch and cache the index from their location, then query the index's meta-data for links to new URLs. A new Agent is created to wrap the matching URL. It maintains a back-reference to its parent, and is known as having a "relative context."
Fetching the index is known as "resolution," and is triggered by the first resolve() or dispatch() call. If the Agent is relative, its parent may need resolution first, so the full ancestry is triggered to resolve in the process. The unresolve() function will clear the cache of the Agent so that it will re-resolve on its next dispatch.
It's useful for me to think of Agents as database cursors.
RUSH (sorry bri, I have to... for the Getty) has a syntax for specifying an Agent in its requests:
myagent> GET foobar-generator
{"foo":"bar"}
RUSH's agents cache the content of their latest request's response, and can have the data resummoned from their own URL:
GET agents/myagent
{"foo":"bar"}
"Bound Agents" can be registered by the page or by workers in order to share control of them. RUSH scripts/commands can then control and configure the programs through the agents.
main_db> HEAD http://myhost.com/db (1)
editor [text] agents/main_db/ctx (2)
- This command requests the headers from that location, effectively moving the agent to that location. Now, when the program uses their main_db Agent, they will be interacting with http://myhost.com/db.
- This command GETs the text/plain content from the editor program and POSTs it to the main_db "Context Proxy." The Context Proxy pipes the request directly to the Agent's current location, so the end-effect of this command is to POST the content of the editor into the myhost.com database.