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
This is a tracking issue that is meant to capture some ideas for re-designing how we communicate from the Tunnel with the individual clients. Currently, this done via callbacks in two places:
From within the Tunnel to the various "glue" crates for the clients
Across the FFI boundary (only Android and Apple)
The content you are editing has changed. Please copy your edits and refresh the page.
The goal is to free connlib from as much platform-specific code as possible. This allows Tun to be a Sink + Stream of IpPackets and all the platform-specific stuff is in the already platform-specific client crates.
Emitting a stream of events changes from a push to a pull design, giving clients more flexibility in handling them by e.g. having access to &mut self, async etc.
We might be able to remove the callbacks across the FFI boundary with a move to UniFFI (#3959) which supports async functions. That would allow Android as well as Swift to use their native co-routine / tasks mechanism to directly respond to the next emitted event and handle it accordingly.
The text was updated successfully, but these errors were encountered:
This is a tracking issue that is meant to capture some ideas for re-designing how we communicate from the
Tunnel
with the individual clients. Currently, this done via callbacks in two places:Tunnel
to the various "glue" crates for the clientsTasks
The goal is to free connlib from as much platform-specific code as possible. This allows
Tun
to be aSink + Stream
ofIpPacket
s and all the platform-specific stuff is in the already platform-specific client crates.Emitting a stream of events changes from a push to a pull design, giving clients more flexibility in handling them by e.g. having access to
&mut self
,async
etc.We might be able to remove the callbacks across the FFI boundary with a move to UniFFI (#3959) which supports
async
functions. That would allow Android as well as Swift to use their native co-routine / tasks mechanism to directly respond to the next emitted event and handle it accordingly.The text was updated successfully, but these errors were encountered: