-
-
Save tylershuster/74d69e09650df5a86c4d8d8f00101b42 to your computer and use it in GitHub Desktop.
>scry
>out of scope as far as just airlock goes
Nothing could be further from the truth! Scries make for excellent on-demand data reading interfaces. Use them, and great things will come to you!
Access-Control-Allow-Origin: *
Guessing this is part of your custom setup?
Mostly skimmed this, but looks good! The whole "cookie as only auth method" thing is obviously unwieldy, but ehh. For your dissection of the cookie it might be more accurate to say that "~zod is the name of the ship being logged in as", but I don't think that has real support at the moment.
deleteandunsubscribewould be good to add- thanks for the point about
nacks - Thanks for the point about poking foreign ships. I might mention it, but it's beyond the scope of this tutorial to delve
- Thanks for the clarification about logging in as. I don't think it will confuse anyone to be more accurate in this regard
- Good catch on the origin headers
Scry/Spider:
https://github.com/urbit/urbit/blob/master/pkg/interface/src/logic/api/base.ts#L57-L68
I can read this, but I don't know how to make it useful. Seems like scry and spider are solid, but lacking documentation. Do you have a reference for some basic understanding of them outside of the context of a particular app?
In general I think that this doc makes for a good "here's a basic connection" tutorial but the more urbity stuff (like Structure of a Chat Message) really should be documented elsewhere, and I can't do it because it's so in flux. If you know of a portions of code that are likely to stay the same, I could start to document those and include them when I PR this.
An authenticated GET request on /~/scry/app-name/path.mark scries into %app-name at the /x/path. If the scry fails, 500. If there is no data, 404. If it succeeds, it tries converting the scry result to the %mark (or %mime if no extension specified), and then converting that to the %mime mark. Asking for json is currently most common, but you could ask for %txt or %jam or whatever.
And spider?
An authenticated POST request on /spider/inputmark/threadname/outputmark.json will attempt to run the threadname thread. It will attempt to convert the JSON in the POST body to inputmark and then use that as the parameters for the thread. Once the thread has completed, spider will attempt to convert the return value of the thread from outputmark to JSON. In the general case, if the thread fails it will return 500. However, if the thread fails with certain messages, it will return a corresponding HTTP status code (see ++thread-http-fail in app/spider.hoon for the mapping and ted/graph/join.hoon for an example of this in use).
Thanks. Considering that graph-store uses this I'm going to have to get my head wrapped around it but it seems a bit...messy for the user just getting started. Do you have simpler examples than the ones I can see in graph.ts? It seems like pretty high cognitive overhead and setup for something that will take a while to use.
I mean, I guess graph-store really eats the world you'll want to know how to interact with it, but hopefully the libraries take care of it for you.
Other than that I think I accounted for y'all's feedback.
spidering
lol, might be more clear to say "running threads" or "starting asynchronous operations" or whatever?
Great work. (:
@liam-fitzgerald, @Fang-, do you have some beginner examples of spidering? thinking of just cutting it if not
Er, "running threads"
🚀
idk if there's any threads you can "just like kick off" super easily, none of the simple ones like -hi etc have mars matching their input...
Well then I will probably just leave a basic syntax and a “here there be monsters” warning. Time to PR
Additional airlock in Swift here: https://github.com/dclelland/UrsusAirlock
Looks good so far @tylershuster !
Worth mentioning:
deleteendpoint (kill the channel)unsubscribeactionjson.Maybe also worthwhile to mention the scry and spider APIs, but kind of out of scope as far as just airlock goes.