Skip to content

The bridge reaches Rust and there is nothing at the far end: no HTTP client, no JSON (RFC-0029 O2–O3) #198

Description

@Briany4717

There is a bridge to Rust, and nothing at the far end

RFC-0028 wired a path from byld to Rust and back. A .byd file can now call
a controller and receive the answer reactively. What it still cannot do is
anything useful with that, because the framework ships no capabilities:

  • No HTTP client. There is no reqwest/ureq/hyper anywhere in the tree.
    A weather app, a feed, anything backed by a remote API, cannot make a request.
  • No JSON. serde_json exists only in byld-lsp. Even an app that brought
    its own HTTP client would have nothing to parse the response with, and no way
    to get the result into the reactive tree as an RFC-0027 record.

So the two-layer model currently says: write Rust. For a weather app that
means every developer writes the same controller, and gets the timeout wrong,
and forgets gzip, and picks native TLS and finds out on the first machine
without OpenSSL.

What "first-party" has to mean, and what it must not

RFC-0029 O2/O3 make these framework capabilities rather than a suggestion in
the docs, so byard new → weather app works with no Rust at all. That is only
defensible if the capability is genuinely non-privileged: an ordinary
Controller, reached through the same inject, answering through the same
ok/err arms, with nothing an app-written controller could not also do.

It also has to be honest about the choices it makes on the app's behalf, and
there are three that cannot be deferred:

A non-2xx: response or error? Both readings are defensible and the language
has to pick one, because a caller writing ok res => { data = res.json } has
already said what it wants on success, and binding a 404's error page into
data is not that.

A body that lies about its content type. A server sending
application/json with a truncated body must not fail the whole request; the
caller needs to see what actually arrived, or the server is undebuggable.

Key order. RFC-0027 records are ordered and a for over one renders in that
order, so a map-backed JSON parse would make a list of fields come back
shuffled between runs — reproducible only in the sense that it is always wrong
somewhere.

Name collisions

Once Http and Json are provided by default, they occupy names an app might
want. RFC-0029 §7 reserves them. Without that, inject Http as http would mean
different things in different apps, and a .byd file would read correctly
against the documentation while doing something else entirely.

Scope

RFC-0029 O2 (Http, reqwest + rustls) and O3 (serde_json ⇄ HostValue, the
Json capability), their feature gating, registration in both hosts, and the
reserved-name rule.

Timers (O4) and persistence (O5) are separate changes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions