Feat/references nav and more content #415
Conversation
|
Thanks for catching this -- I knew the section name was mismatched with the URL path, but didn't know it was also mismatched between top nav and sidebar nav. I'd suggest we do this, but rename it all to 'Resources', which I feel accommodates both references and the other stuff you're adding, plus non-buildy howtos. I've just asked @MatthewNichols if that goes against some empirical findings they made when they were doing usability testing. Suspect it's okay to change though. |
Looks like you've done this in #429 -- happy to have you merge that into this PR but lmk if you need me to. |
|
yup, I'll merge that into this once it's approved -- it's really basic but feels like it's kind of a dependency for a lot of other restructurings we want to do. |
|
|
||
| When you write a Holochain application, the part that lives in Holochain is called a [DNA](../concepts/2_application_architecture/#layers-of-the-application-stack). It runs in a WebAssembly sandbox and talks to the host, or conductor, through the host API. The Rust HDK (Holochain Development Kit) makes it easy for you to write your DNAs in the Rust programming language. | ||
| When you write a Holochain application, the part that lives in Holochain is called a [DNA](/concepts/2_application_architecture/#layers-of-the-application-stack). It runs as a guest in a WebAssembly sandbox and talks to the host, or Holochain conductor, through the host API. It's also expected to implement callbacks that the conductor needs to call at certain times. The HDK and HDI Rust crates make it easy for you write guest code that interfaces with the conductor --- the HDK for your DNA's [coordinator zomes](/resources/glossary/#coordinator-zome) and the HDI for [integrity zomes](/resources/glossary/#integrity-zome). |
There was a problem hiding this comment.
I think this is TMI for this section. But lets leave it for now -- once we have a Build section it can be moved there.
|
|
||
| For both of these APIs, you make an RPC call sending a MessagePack-serialized request to the conductor over WebSocket and listening for a response. On the interface that exposes the app API, you can also listen for [**signals**](./glossary/#signal) broadcast by cells. | ||
| For both of these APIs, you make an RPC call sending a MessagePack-serialized request in a special envelope format to the conductor over WebSocket and listen for a response. The request's envelope must contain a request ID, and the matching response will have the same ID. On the interface that exposes the app API, you can also listen for [**signals**](/resources/glossary/#signal) broadcast by cells. There are [client libraries](#conductor-clients) for JavaScript and Rust that make it easy to handle requests/responses and set up signal listeners. |
There was a problem hiding this comment.
I think this is TMI for this section. But lets leave it for now -- once we have a Build section it can be moved there.
Overview
@pdaoust I thought about linking to existing example apps (i.e. acorn, mewsfeed), and/or to existing dev agencies (dark soil, lightningrodlabs, etc.). Do either of these make sense to you?