How a read client reaches a KB — directly in-process, or over the daemon HTTP API
(vaelii.host.serve). It re-exports the slice of the vaelii.core read surface the
browser uses, so the browser is written once against these names and runs unchanged
against a local KB or a remote daemon.
A target is either a KB, read in-process, or an access value from remote. A
KB-read op dispatches on it:
:remote → the client (vaelii.host.client/call) — one HTTP round-trip
a KB → vaelii.core, via serve/ops (the very allowlist the daemon serves, so
local and remote answer through the same table and cannot drift)
The pure display fns (term-role, reified-term?, readable-sentence,
indexable-terms, negative?, rests-on, query-contexts, assertable-strengths,
sort-by-content, levels, calculi), the bootstrap fns (open-kb, clear!), the
in-process write-hazards and the process-wide switch-value take no target and
delegate to vaelii.core. They are here so a caller can require this one namespace
and reach the whole surface it needs.
Reads — including check / check-edit, which answer what assert would refuse
and write nothing — plus the four writes the browser performs: edit (an
assert/retract batch in one settle), edit-with-consequences (the same batch, plus
the belief it moved), forward-chain, and preview (which stores nothing but applies
a batch and rolls it back, so it holds the single writer). A remote result is already
EDN-clean (the daemon projects sentex records to maps); a local result is the raw
record, and both answer to the same keys, so a caller handles them identically.
How a *read* client reaches a KB — directly in-process, or over the daemon HTTP API
(`vaelii.host.serve`). It re-exports the slice of the `vaelii.core` read surface the
browser uses, so the browser is written once against these names and runs unchanged
against a local KB or a remote daemon.
A **target** is either a KB, read in-process, or an access value from `remote`. A
KB-read op dispatches on it:
:remote → the client (`vaelii.host.client/call`) — one HTTP round-trip
a KB → `vaelii.core`, via `serve/ops` (the very allowlist the daemon serves, so
local and remote answer through the same table and cannot drift)
The pure display fns (`term-role`, `reified-term?`, `readable-sentence`,
`indexable-terms`, `negative?`, `rests-on`, `query-contexts`, `assertable-strengths`,
`sort-by-content`, `levels`, `calculi`), the bootstrap fns (`open-kb`, `clear!`), the
in-process `write-hazards` and the process-wide `switch-value` take no target and
delegate to `vaelii.core`. They are here so a caller can require this one namespace
and reach the whole surface it needs.
Reads — including `check` / `check-edit`, which answer what `assert` would refuse
and write nothing — plus the four writes the browser performs: `edit` (an
assert/retract batch in one settle), `edit-with-consequences` (the same batch, plus
the belief it moved), `forward-chain`, and `preview` (which stores nothing but applies
a batch and rolls it back, so it holds the single writer). A remote result is already
EDN-clean (the daemon projects sentex records to maps); a local result is the raw
record, and both answer to the same keys, so a caller handles them identically.(clear-caches target)Drop the target's derived caches and say what went (vaelii.core/clear-caches).
Filed here rather than with the reads because it mutates, and not with the writes above because what it mutates is not knowledge: no belief moves, every entry it drops the next read recomputes, and it holds no writer. So it is the one control on this facade that is safe to use while a load runs — which is when a reader most wants it, since a hit rate means nothing until you can watch a miss.
Drop the target's derived caches and say what went (`vaelii.core/clear-caches`). Filed here rather than with the reads because it mutates, and *not* with the writes above because what it mutates is not knowledge: no belief moves, every entry it drops the next read recomputes, and it holds no writer. So it is the one control on this facade that is safe to use while a load runs — which is when a reader most wants it, since a hit rate means nothing until you can watch a miss.
(edit! target batch)Apply an edit batch to the target, local or over the daemon. batch is
{:add [[sentence context opts?]…] :remove [handles…]}; adds land before removes and
the whole thing settles once (vaelii.core/edit!). Both of the browser's mutations —
saving edited sentexes, asserting new ones, retracting a selection — are this one
call, so every write it makes is one settle.
Apply an edit batch to the target, local or over the daemon. `batch` is
`{:add [[sentence context opts?]…] :remove [handles…]}`; adds land before removes and
the whole thing settles once (`vaelii.core/edit!`). Both of the browser's mutations —
saving edited sentexes, asserting new ones, retracting a selection — are this one
call, so every write it makes is one settle.(edit-with-consequences! target batch)(edit-with-consequences! target batch opts)edit, and what the batch turned out to mean — the belief it added and took away
(vaelii.core/edit-with-consequences!, docs/preview.md). The browser's commit paths
use this rather than edit so a page can say what followed from a save; the extra
answer is sentences and handles, EDN-clean, so it crosses the wire like any read.
`edit`, and what the batch turned out to mean — the belief it added and took away (`vaelii.core/edit-with-consequences!`, docs/preview.md). The browser's commit paths use this rather than `edit` so a page can say what followed from a save; the extra answer is sentences and handles, EDN-clean, so it crosses the wire like any read.
(forward-chain target & args)Run the forward-chaining fixpoint over the target's KB — {:derived n :truncated? bool}. A write (it derives and places conclusions), and the browser's one way to
ask what a load's rules would conclude without asserting anything new.
Run the forward-chaining fixpoint over the target's KB — `{:derived n :truncated?
bool}`. A write (it derives and places conclusions), and the browser's one way to
ask what a load's rules would conclude without asserting anything new.(local-kb target)The in-process KB behind target, or nil when the target is a remote daemon.
Every op above works either way, so a caller that only reads never needs this. It is
for the one thing that cannot go over the wire: handing the KB itself to a component
written against vaelii.core rather than against this facade — a browser extension
that reads a term's neighbourhood, its vocabulary and its checks through dozens of
calls, which a round-trip at a time is not a thing to offer a reader. A nil answer
lets the caller say so, rather than degrade silently.
The in-process KB behind `target`, or nil when the target is a remote daemon. Every op above works either way, so a caller that only reads never needs this. It is for the one thing that cannot go over the wire: handing the KB itself to a component written against `vaelii.core` rather than against this facade — a browser extension that reads a term's neighbourhood, its vocabulary and its checks through dozens of calls, which a round-trip at a time is not a thing to offer a reader. A nil answer lets the caller say so, rather than degrade silently.
(preview target batch)(preview target batch opts)What editing batch would make the target believe and stop believing, without
leaving it done (vaelii.core/preview, docs/preview.md).
Filed with the writes although it stores nothing: it applies the batch and rolls it back, so it holds the single writer for its duration and is not a thing to run beside one. The answer is EDN-clean either way — sentences and handles, no records — so it crosses the wire like any read.
What `edit`ing `batch` would make the target believe and stop believing, without leaving it done (`vaelii.core/preview`, docs/preview.md). Filed with the writes although it stores nothing: it applies the batch and rolls it back, so it holds the single writer for its duration and is not a thing to run beside one. The answer is EDN-clean either way — sentences and handles, no records — so it crosses the wire like any read.
(remote host port)A remote access to the daemon at host:port — builds a client connection the
KB-read ops send over.
The connection reads VAELII_API_TOKEN like any other (client/client), so a
browser attached to an authenticating daemon carries the token by being started in
the same environment. There is nothing here to configure and no second place to say
it: the target is a host and a port, and the credential is the process's.
A remote access to the daemon at `host`:`port` — builds a client connection the KB-read ops send over. The connection reads `VAELII_API_TOKEN` like any other (`client/client`), so a browser attached to an authenticating daemon carries the token by being started in the same environment. There is nothing here to configure and no second place to say it: the target is a host and a port, and the credential is the process's.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |