remoting API

[hexfusion]

As the popularity of bootc grows a central location for go types/examples would be useful for projects. Speaking with @cgwalters he is willing to consider something similar to rpmostree-client-go[1] for bootc but there is some intersection with [2].

Curious if instead of creating go client as a os exec wrapper, exposing some of the Rust functionality via CGO? Please include me in future conversations on the topic if possible 🙏 Wasmtime CGO examples as ref. [3],[4]. I understand that CGO is not ideal but in terms of interaction with Rust over FFI, I don't believe there is another option.

[1] https://github.com/coreos/rpmostree-client-go/
[2] #518
[3] https://github.com/bytecodealliance/wasmtime/blob/b869b66bce8a57c9e83db4e3bcd6809d88e94a5f/crates/c-api/src/types/extern.rs#L39
[4] https://github.com/bytecodealliance/wasmtime-go/blob/cabc733f95623fb897b2c35266124192ffca94b4/externtype.go#L9C12-L9C29

[cgwalters]

Curious if instead of creating go client as a os exec wrapper, exposing some of the Rust functionality via CGO

My experience with CGO has not been great. We don't have strong high performance needs here right? An IPC framework of any form is almost certainly going to be dramatically safer and easier to maintain.

I would start with a simple "stable CLI with --json output" as the lowest common denominator to start, which is almost what we have - we just need to stabilize the CLI and json schema.

But, if we needed to go to IPC, my preferences would be one of:

• https://capnproto.org/
• https://varlink.org/

[cgwalters]

This issue also intersects with #2

[cgwalters]

I've added this to the 1.2 milestone (next month) as it's pretty important for coreos/rpm-ostree#4994

As of currently...I am slightly leaning towards varlink.

[cgwalters]

OK I'm digging in a bit more to varlink. It does seem like a relatively decent fit conceptually with our current daemonless architecture. But it's pretty obscure now outside of systemd. Doing a code search for Rust users turns up almost nothing, although it is notable that the SerpentOS folks are doing a rewrite in Rust...a lot going on in those repositories, we should probably talk to them at some point.

One hit I dug into there actually ended up in them removing varlink - as podman also did famously, although they had the constraint of needing to support the Docker HTTP API.

I think the main thing we'll want for the install and update phases is basically:

• check-for-update size
• progress reporting (e.g. image download details at a byte level)
• structured errors

This all seems relatively straightforward to do via varlink (though I gotta say while I understand the choice of JSON, not trying to handle the 64 bit integer problem there is just...ugh. Yes in reality, most of our data sizes should be within safeint).

---

Of the other options here (gRPC, capnproto) I guess lately I'd lean more a bit to gRPC just because it's a good bit more widely used and very well maintained.

[cgwalters]

I looked a bit more at users of gRPC over Unix domain socket (what we definitely want here) and came upon hyperium/h2#487 which is also pretty telling (in the opposite direction, most gRPC users are over TCP).

@sashagrunert any opinions on this?