Looks 99.95% good to me! Thanks for providing this summary, @The-A-Man!
Only a few clarifications/corrections:
This is true about both host API functions and the callbacks you’re expected to write (including zome functions). My clarification is that the single argument could be seen as an ‘args object’, so any function that wants to take multiple parameters should have its own struct with params as properties. You see this in a lot of the host functions. Feels very Smalltalk-y to me
that was a hard adjustment for me, and I’m glad they have the syntactical sugar functions to make it easier. My correction is that the convention for validation callback names (given an entry type of foo
) goes like this:
-
validate_create_entry_foo
will only be called forcreate
actions that speak entries of typefoo
into existence -
validate_update_entry_foo
andvalidate_delete_entry_foo
will do the same forupdate
anddelete
actions -
validate_create_entry
will be called for all app entries in this zome, even ones of typefoo
-
validate_create_agent_id
,validate_update_agent_id
, andvalidate_delete_agent_id
will be called for the agent ID sys entry (there are two other sys entry types,cap_grant
andcap_claim
) -
validate_create
,validate_update
, andvalidate_delete
will be called for all app entry and system entry types -
validate_create_link
andvalidate_delete_link
will be called for all links (created by this zome? not sure)
One interesting thing is that these functions ‘cascade’ – that is, if you’ve defined validate_create_entry_foo
, validate_create_entry
, and validate_create
, all three of them will be called in descending order of specificity until one returns an indeterminate* or unsuccessful result.
* By ‘indeterminate’ I mean that maybe a create-entry action required some DHT data for its validation but that data couldn’t be pulled from the DHT – in this case your validation callback can give back a list of hashes it’s waiting for, and the conductor will try again later.
Glad you like the new HDK so far too — I got good feels from it when I got my first glimpses of it. (Except validation functions – I hate switch statements. Glad to see the added sugar now.) What is it you don’t like about capabilities?
Sorry to hear about everyone’s experiences on WSL2 — a few months back, I had someone help me test all the tutorials on WSL2 and he didn’t hit any roadblocks. Is it WSL itself that crashes, or the Holochain runtime, or the Rust compiler, or something else?
What I found frustrating with running Holochain in Docker is that, because the HTTP and RPC-over-WebSocket ports were bound to 127.0.0.1
, everything UI-related had to be inside the Docker container. I tried so hard to set up SSH tunnels to the host and never could get it to work. Did either of you have any success?