You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use Capnp messages for cosim message serialization, but we don't on real hardware. This has been a real source of pain. Let's do away with the Capnp message generation and switch to a blob of data which would be the same as in real hardware.
So the capnp schema would go from what it is today:
interface EsiDpiEndpoint @0xfb0a36bf859be47b (SendMsgType, RecvMsgType) {
# Send a message to the endpoint.
send @0 (msg :SendMsgType);
# Recieve a message from the endpoint. Non-blocking.
recv @1 (block :Bool = true) -> (hasData :Bool, resp :RecvMsgType);
to
interface EsiDpiEndpoint {
# Send a message to the endpoint.
send @0 (msg :Data);
# Recieve a message from the endpoint. Non-blocking.
recv @1 (block :Bool = true) -> (hasData :Bool, resp :Data);
And ESI would not be generating a Capnp schema at all. This would also have the side effect of reducing out dependence on Capnp -- which has been an absolute pain -- and longer term replace it with another protocol.
@mortbopet WDYT? I spent an obnoxious amount of time on this (and you spent a long time struggling with it for the C++ API), so while it's cool, I don't see it being worth the upkeep.
The text was updated successfully, but these errors were encountered:
+1 - If we're confident that ESI will revolve around serialization/deserialization using a schema that's communicated out-of-band/dynamically, then let's just get rid of this and all of the complexity that followed along with it.
It might make sense to bring this back at some point in the distant future (e.g., for network comms) but at that point we'll probably not be using Capnp since it's not used for software like anywhere.
We currently use Capnp messages for cosim message serialization, but we don't on real hardware. This has been a real source of pain. Let's do away with the Capnp message generation and switch to a blob of data which would be the same as in real hardware.
So the capnp schema would go from what it is today:
to
And ESI would not be generating a Capnp schema at all. This would also have the side effect of reducing out dependence on Capnp -- which has been an absolute pain -- and longer term replace it with another protocol.
@mortbopet WDYT? I spent an obnoxious amount of time on this (and you spent a long time struggling with it for the C++ API), so while it's cool, I don't see it being worth the upkeep.
The text was updated successfully, but these errors were encountered: