Plan - dat_container_runtime

[alyhxn]

todo

---

• [ ] Plan - dat_container_runtime

  • @input :package: discord_thread
  • [x] Discussion - 2h
  • [x] Understanding the code - 4h
  • [x] Repaired ana-test and bob-test fake connection - 2h

  • @output :package: dat_container_runtime_v0.0.1

• [ ] Update - dat_container_runtime

  • [ ] Get rid of budo and browserify
  • [ ] Implement shortcuts described here discord_msg
  • [ ] Save the state of all vaults
  • [ ] Implement settings for devtools-vault which displays ana and bobs data/stats/communication and gives controls

[alyhxn]

tasks - 2024.06.04

• Plan - dat_container_runtime
  • @input :package: discord_thread
  • Discussion - 2h
  • Understanding the code - 4h
  • Repaired ana-test and bob-test fake connection - 2h
  • Logged tasks - 10min
  • @output :package: dat_container_runtime_v0.0.1

[alyhxn]

tasks - 2024.06.05

• Update - dat_container_runtime_v0.0.1
  • Setup the localStorage through MessageChannel - 3h
  • Logged tasks and recorded video - 10min
  • @output :package: dat_container_runtime_v0.0.2

---

Worklog

worklog-211

[serapath]

feedback 2024.06.05

I havent looked at the actual code DIFF yet and am waiting for the pull request, so the following feedback is based on the worklog video alone.

and

If the get call in the second screenshot is the same as the function get in the first one, then i wonder what is supposed to happen here.

The .postMessage call does not return anything. Any potential message that gets send back by the receiver ot the posmessage will be received in the port.onmessage = event => {} function.

So the back and forth is quite a bit more involved then who this what i see here is maybe assumed to work :-)

But the idea you are describing is the correct one otherwise. We definitely need and should solve this the way you say.

For example here you are on the right track, but that wont work yet.

So when you do a .postMessage there is no way how you can easily relate a sent message to a message received in the future, which is why we have a very opinionated message structure that we need to comply with.

const message = { head, refs, type, data, meta }

Where const head = [by, to, mid] and that message ID is supposed to be 0 for the first message sent from by to to and then increased by +1 for every future message.

For any pair of unique sender and receiver (by and to), there is only a single message 1 or 2 and so on, which makes head globally unique.

So after sending a message, there would need to be an object, let's say const wait = {} and we store maybe a callback for how to continue, e.g. like this:

const wait = {}

const message = { ... }
const response = await send(message)

async function send (message) {
  const { resolve, reject, promise } = Promise.withResolvers()
  wait[message.head] = { resolve, reject, next }
  port.postMessage(message)
  function next (message) { resolve(message) }
}

// and then elsewhere or before:
port.onmessage = onmessage

function onmessage (event) {
  const message = event.data
  const handler = wait[message.refs.cause]
  if (handler) {
    delete wait[message.refs.cause]
    handler(message)
  }
}

In this case, a sender is a specific program i guess. So behind the scenes there should be one or more db book for every program and then those sent and received messages should be appended as pages to that book. The book is basically just an array for us for now.

So for any combination of by and to there is a book. And for each message.head that uses that exact by and to, the mid is the "page number".

Also, for by=ana and to=bob, the book that stores all replies would be by=bob and to=ana... if that makes sense :-)