khan: comment changes

Not sure we actually want to guarantee exactly-once response semantics,
so you can't rely on request ordering to correlate requests even if you
never send simultaneous requests.

Also do a worked example of a %urth scry, which hopefully raises the
question of whether %urth should try to support views.
This commit is contained in:
Jōshin 2021-12-25 20:42:19 +00:00
parent d505541498
commit b61f4e5728
No known key found for this signature in database
GPG Key ID: A8BE5A9A521639D0

View File

@ -13,11 +13,9 @@
** **
** request-id is a 31-bit client-supplied identifier that will ** request-id is a 31-bit client-supplied identifier that will
** be returned along with the response, to allow correlating ** be returned along with the response, to allow correlating
** responses to simultaneous requests. (any request that may ** responses with requests. it may be reused; e.g. 0 could be
** take more than a single arvo event is not guaranteed to ** supplied every time for a client that doesn't care about
** return in order.) it may be reused; e.g. 0 could be supplied ** responses.
** every time for a client that never sends simultaneous
** requests or that doesn't care about responses.
** **
** %fyrd is a request to run a thread. its arguments are ** %fyrd is a request to run a thread. its arguments are
** described in the %khan vane, which handles these. it produces ** described in the %khan vane, which handles these. it produces
@ -35,9 +33,13 @@
** $+ each path ** $+ each path
** $% [%once vis=view syd=desk tyl=spur] ** $% [%once vis=view syd=desk tyl=spur]
** [%beam vis=view bem=beam] ** [%beam vis=view bem=beam]
** [%urth *] ** [%urth urth-args=*]
** == ** ==
** **
** so e.g. a full %urth peek request might look like:
**
** [`@ud`%id %peek | %urth %mass ~]
**
** %move is a kernel move. these are injected into arvo, except ** %move is a kernel move. these are injected into arvo, except
** again for a runtime overlay. ** again for a runtime overlay.
** **