Apparently the operation triggered by this generator may cause the rift
for the specified moon to be inaccurate if |moon-breach was run
previously.
Here, detect if the moon has been created before, and recommend the
other generators if that is the case.
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.
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.
Apparently the operation triggered by this generator may cause the rift
for the specified moon to be inaccurate if |moon-breach was run
previously.
Here, detect if the moon has been created before, and recommend the
other generators if that is the case.
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.
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.
