search

kinode-dao / kinode-book

"Rust Book"-style introduction and documentation for Kinode OS
Apache License 2.0
12 stars 8 forks source link

Section 2.8. Terminal #181

Closed jurij-jukic closed 6 months ago

jurij-jukic commented 6 months ago

  1. I feel like the list of commands should be on a separate reference page. All docs in section 2 were conceptual, so it feel weird to have this here. Though, I'm not really sure where to put it.

  2. 'For your scripts to be usable by the terminal, you must include a pkg/scripts.json file.'

    • at which subfolder exactly? does this refer to when you have your own package? I found this but thats a core package. it would be a good example, but it should somehow be made clear that that's not where it should be edited (?)

  3. 'grantCapabilities (Array): An array of ProcessIds as strings which represent which processes will be able to message this script back'

    • is messaging the script back equivalent to having full capability? I assume in this context, yes, because it's just a script, but in general capabilities can be more elaborate (with an object that contains issuer and params)
nick1udwig commented 6 months ago
  1. Good point. Please make an issue and we can address later
  2. Best discussion of package directory format is here as far as I know. Yeah, I like the idea of linking terminal's scripts.json (with the notes/caveats you mention)
  3. It is a messaging capability: if you don't have it and the process is not public you cannot message them. Feel free to make this sentence clearer
jurij-jukic commented 6 months ago
  1. It is a messaging capability: if you don't have it and the process is not public you cannot message them. Feel free to make this sentence clearer does this mean:
    • if the process doesnt have a messaging capability granted by the script and that process is not public, it cannot message the script?
    • also, why would a process need to be public to message the script?
jurij-jukic commented 6 months ago
  1. change camelCase paramters to snake_case (we neglected to update this when code changes and so should do it now while we're here)

PackageId stays camelCase, correct?

nick1udwig commented 6 months ago

PackageId stays camelCase, correct?

Yes -- rust types are like FooBar, but all our json fields should be like hello_world.

nick1udwig commented 6 months ago
  1. It is a messaging capability: if you don't have it and the process is not public you cannot message them. Feel free to make this sentence clearer does this mean:
  • if the process doesnt have a messaging capability granted by the script and that process is not public, it cannot message the script?
  • also, why would a process need to be public to message the script?

Sorry, when I say a process, P, "has a cap" I mean "a process/module has granted P a cap. So what I meant here was: when you set foo:bar:baz.os in your scripts grant_capabilities field, you are giving foo:bar:baz.os the messaging capability for your script so that it can message your script back, e.g., to Respond with whatever result.

So in general, a process must either grant messaging for you to message them OR they can register as public in which case anyone can message them.

jurij-jukic commented 6 months ago

added a link to terminal syntax at the top of the page, please check