External gRPC

[jwinarske]

Interested in supporting external ASIO/gRPC C++, with a connection to Dart via isolate bridge.

It's there an easy way to pass off a serialized gRPC messages in Dart to a virtual isolate, and parse incoming message from an isolate?

I have an isolate zero-copy "bridge" working in both C++ and Rust.

[mraleph]

Hi @jwinarske. I am not entirely sure I understand the question. Could you clarify?

If you just want to exchange messages inprocess then maybe you don't need full blown gRPC machinery? You could just send protobuf encoded messages back and forth.

Alternatively you could try to wrap your "bridge" as a ClientChannel implementation - this way you can reuse gRPC client stubs.

But I am just guessing what you are trying to achieve here.

[jwinarske]

@mraleph

The goal is zero copy Dart <-> gRPC C++, and reuse as much boiler plate from the generated code as possible.

I like the idea of wrapping the "bridge" as a ClientChannel.

In the Automotive Grade Linux design, many micro-services each expose an independent API. Each micro-service gets their own set of IDL files. I want to unify this collection of APIs into a logical API on the Dart side, using a common zero-copy interface.

One example of a micro-service: SDR for AM/FM/DAB/DAB+ bands

[jwinarske]

Closed by accident

[jwinarske]

The "bridge" is implemented in C++17 leveraging asio-gRPC + libunifex. It will be open sourced.

[mraleph]

The goal is zero copy Dart <-> gRPC C++, and reuse as much boiler plate from the generated code as possible.

gRPC will not be zero-copy though - you need to serialize - deserialize messages as they cross the boundary.

You need to share underlying protobuf messages between C++ and Dart to make it zero-copy, which is currently not possible. Though it might become possible when bindings for
upb become available.

[jwinarske]

Though it might become possible when bindings for
upb become available.

Any timeline on potential bindings for upb?

[mraleph]

No concrete timeline right now.