Open kitlith opened 3 years ago
hmm, i think there's going to be a bit more involved here, actually.
First off, ClientMessage
, DeviceMessage
, and ButtplugFFIServerMessage
have unused fields, in the form of id (and index for device), and otherwise wrap *.FFIMessage
. We should be able to ditch those unused fields, and then bring the contents of FFIMessage into the outer message, meaning that an inner FFIMessage is no longer necessary.
Second off, I think the Ok and Error messages can be lifted up to the top level, and we can start creating 'Result' messages. i.e.
message ResultVoid {
oneof msg {
Ok ok = 1;
Error error = 2;
}
}
message ResultDeviceEvent {
oneof msg {
DeviceEvent ok = 1;
Error error = 2;
}
}
maybe with types for the individual sub-messages of DeviceEvent instead of DeviceEvent itself, to make some things potentially even easier.
also, TIL about protobuf's service definition, which is separated from gRPC -- aka we can build our own """RPC""" system that can work with protobuf that serves our need of crossing the FFI boundary. This may be worth further investigation.
mark this as something to consider for ffi core 3.0 i guess, if we don't decide to nix protobuf entirely by then.
Feature Description
See title, the idea is that since every call now takes a callback, we can more strongly type the protobuf messages that consumers receive back from FFI proper.