Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spider: support speaking raw nouns #6943

Merged
merged 4 commits into from Apr 5, 2024
Merged

spider: support speaking raw nouns #6943

merged 4 commits into from Apr 5, 2024

Conversation

Fang-
Copy link
Member

@Fang- Fang- commented Mar 20, 2024

in the thread-calling http interface.

Specifying a content-type header of application/x-urb-jam will make the request body be interpreted as a @uw-encoded jammed noun, rather than json.

Specifying an accept header of application/x-urb-jam will make the thread result in the response body be rendered as a @uw-encoded jammed noun bytes, rather than json.

For the latter, the output mark becomes unused, since we can just "render" the resulting noun directly, without needing to explicitly convert it. (This assumes that converting any mark to %noun will always result in the same noun, which isn't guaranteed in theory, but is always the case in practice.)

This maps closely to is adjacent to Eyre's "noun channels" support, and prepares spider for use in a nouns-based version of the js-http-api.

Example:

$ curl --silent -X POST --data \x02 --header 'content-type: application/x-urb-jam' --header "cookie: urbauth-~zod=0v4.8lljk.ujoa5.t05b7.iako9.npqet" --header 'accept: application/x-urb-jam' http://localhost/spider/base/ship/hi/noun | xxd -p
003ed0d240fcf4dec840e6eac6c6cae6e6ccead8
> `@uw`(jam ~zod)
0w2
> ;;(@t (cue 0xd8ea.cce6.e6ca.c6c6.eae6.40c8.def4.fc40.d2d0.3e00))
'hi ~zod successful'

in the thread-calling http interface.

Specifying a content-type header of application/x-urb-jam will make the
request body be interpreted as a uw-encoded jammed noun, rather than
json.

Specifying an accept header of application/x-urb-jam will make the
thread result in the response body be rendered as a uw-encoded jammed
noun, rather than json.

For the latter, the output mark becomes unused, since we can just
"render" the resulting noun directly, without needing to explicitly
convert it. (This assumes that converting any mark to %noun will always
result in the same noun, which isn't guaranteed in theory, but is always
the case in practice.)

This prepares spider for use in a nouns-based version of js-http-api.
@Fang- Fang- requested review from yosoyubik and pkova March 20, 2024 14:00
@Fang- Fang- changed the title spider: support speaking raw (uw-encoded) nouns spider: support speaking raw nouns Mar 26, 2024
This brings it in line with the serialization found in /mar/noun.

The `@uw`-encoding was carried over from Eyre, who uses it for channels.
In that context, outgoing jam bytes must be encoded, because newline
characters (`0a` bytes) would break up the SSE data field. Because
they're essentially part of the same protocol, Eyre mirrors this for
incoming nouns. Even though PUT requests can carry arbitrary bytes just
fine, the symmetry and protocol-wide consistency seems important.

Here, we are dealing strictly with plain HTTP requests, and strictly
with requests that have indicated support for the
`application/x-urb-jam` mime type to boot. We should have no qualms
about raw jam bytes. They're more compact/efficient, too.
Fang- added a commit to xiphiness/js-http-api that referenced this pull request Mar 26, 2024
Now defaults to speaking raw nouns with spider, as supported through
urbit/urbit#6943.

Provides a jsonThread() fallback for speaking json. Doesn't yet support
the "json one way, nouns the other" case.

Factors out noun<->bytebuffer conversions into utility functions.
@pkova pkova merged commit 3c33d25 into develop Apr 5, 2024
1 check passed
@pkova pkova deleted the m/spider-http-nouns branch April 5, 2024 12:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants