Skip to main content

Module workspace

Module workspace 

Source
Expand description

Following a link — the one step that needs a workspace to take it in.

crate::links says a metadata row is a link and what it says; this module says where that link lands. The two are separate because the second costs something the first does not: a root to resolve /-absolute targets from, a registry to turn id:ajp7eq into a path, and the filesystem to say whether the answer is actually there. A frontend that only draws links differently should not pay for any of it.

WorkspaceView is prov’s read surface with the pieces an editor needs resolved once and kept: the effective config, the vocabularies its controlled fields point at, the Facets its vocabulary implies, and the Schema a content document is edited under. It is a view — the name is the promise. Nothing here writes.

§Read-only, and why that is not a temporary state

Following a link reads. Editing one does not: a relation field is half of a pair prov maintains bidirectionally, so writing contents in one document means writing part_of in another, and that is prov’s mutate layer rather than its edit layer. This crate’s metadata backend edits one document’s bytes and has no way to touch a second, which is exactly why the scope line is where it is. So a frontend may follow a link with what is here and must not conclude it can retarget one.

prov’s read surface is async over a filesystem port. Nothing here is, because an editor’s “open the document under the cursor” is a foreground action with nothing to overlap: each entry point blocks with prov’s own block_on, which is the same executor prov’s CLI uses.

Structs§

WorkspaceView
One workspace, opened for reading, with everything an editor resolves once.

Enums§

Destination
Where a link lands.

Functions§

resolve_without_workspace
Where a link points with no workspace to resolve it in — the lexical floor, for a document opened on its own.