@@ -163,7 +163,7 @@ it: Subscribing to other agents. This is done by `%pass`ing the target agent a
163[%pass /some/wire %agent [~some-ship %some-agent] %watch /some/path]
163[%pass /some/wire %agent [~some-ship %some-agent] %watch /some/path]
166−If yor agent's subscription request is successful, updates will come in to your
166+If your agent's subscription request is successful, updates will come in to your
167agent's `on-agent` arm on the `wire` specified (`/some/wire` in this example).
167agent's `on-agent` arm on the `wire` specified (`/some/wire` in this example).
168The `wire` can be anything you like - its purpose is for your agent to figure
168The `wire` can be anything you like - its purpose is for your agent to figure
169out which subscription the updates are for. The `[ship term]` pair specifies the
169out which subscription the updates are for. The `[ship term]` pair specifies the
@@ -228,7 +228,7 @@ an error message fed into the `on-fail` arm of your agent.
228## Receiving updates
228## Receiving updates
230Assuming the `%watch` succeeded, your agent will now begin receiving any
230Assuming the `%watch` succeeded, your agent will now begin receiving any
231−`%fact`s the other agent publishes on the path to which you've subscribed. These
231+`%fact`s the other agent publishes on the `path` to which you've subscribed. These
232`%fact`s will also come in to your agent's `on-agent` arm in a `sign`, just like
232`%fact`s will also come in to your agent's `on-agent` arm in a `sign`, just like
233the initial `%watch-ack`. The `%fact` `sign` will have the following format:
233the initial `%watch-ack`. The `%fact` `sign` will have the following format:
@@ -238,7 +238,7 @@ the initial `%watch-ack`. The `%fact` `sign` will have the following format:
239You would typically handle such `%fact`s in the following manner: Test the
239You would typically handle such `%fact`s in the following manner: Test the
240`wire`, test whether the `sign` is a `%fact`, test the `mark` in the `cage`,
240`wire`, test whether the `sign` is a `%fact`, test the `mark` in the `cage`,
241−extract the data from the `vase` in the `cage`, and apply your logic. For example:
241+extract the data from the `vase` in the `cage`, and apply your logic. Again, route on `wire` before `sign` is one of the [Precepts](/docs/development/precepts#specifics). For example:
244++ on-agent
244++ on-agent
@@ -263,7 +263,7 @@ The `on-agent` arm produces a `(quip card _this)`, so you can produce new
264## Getting kicked
264## Getting kicked
266−For whatever reason, the agent you're `%watch`ing might what to kick your agent
266+For whatever reason, the agent you're `%watch`ing might want to kick your agent
267from a `path` to which it's suscribed, ending your subscription and ceasing to
267from a `path` to which it's suscribed, ending your subscription and ceasing to
268send your agent `%fact`s. To do this, it will send your agent a `%kick` card [as
268send your agent `%fact`s. To do this, it will send your agent a `%kick` card [as
269described above](#kicking-subscribers). The `%kick` will come in to your agent's
269described above](#kicking-subscribers). The `%kick` will come in to your agent's
@@ -538,6 +538,8 @@ currently exists, getting the new subscriber up to date.
539### Subscriber
539### Subscriber
541+#### `/app/todo-watcher.hoon`
543/+ default-agent, dbug
545/+ default-agent, dbug
@@ -620,7 +622,7 @@ currently exists, getting the new subscriber up to date.
622This is the subscriber agent. Since it's just for demonstrative purposes, it has
624This is the subscriber agent. Since it's just for demonstrative purposes, it has
623−no state and just prints updates it receives. In practice it would keep the
625+no state and just prints the updates it receives. In practice it would keep the
624`tasks` map it receives in its own state, and then update it as it receives new
626`tasks` map it receives in its own state, and then update it as it receives new