-
-
Save tylershuster/74d69e09650df5a86c4d8d8f00101b42 to your computer and use it in GitHub Desktop.
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
deleteandunsubscribewould be good to addnacksScry/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.