Hi Kenton, That makes sense, thank you!
A theoretical point perhaps is that one might want to keep the handl alive by passing it to another longer-lived VAT, whereas the lifetime of a promise is bound by the VAT it's running in. Vaci On Wednesday, 24 August 2022 at 18:45:32 UTC+1 [email protected] wrote: > The promise approach is more elegant and efficient. Historically it has > sometimes led to complications, though. Particularly tricky is > bidirectional streaming. > > subscribe(downstream :Downstream) -> (upstream :Upstream) > > The problem here is that all messages sent to `upstream` will normally be > held until `subscribe()` itself returns a capability which they can be sent > to. So if `subscribe()` doesn't return until the downstream direction is > done (or canceled), then the upstream doesn't work. > > HOWEVER, if you're using the C++ implementation, a solution to this was > introduced two or so years ago. You can use `context.setPipeline()` to > connect the pipelined capabilities without actually completing the RPC. > > So, assuming you can rely on `setPipeline()` being available, then I would > lean towards the promise approach rather than the handle approach. > > -Kenton > > On Wed, Aug 24, 2022 at 11:00 AM Vaci <[email protected]> wrote: > >> If a capability accepts a callback as a method param, such as for >> subscriptions, then it seems there are (at least) two possible ways to >> handle cancellation: >> >> a) return a handle that can be dropped to cancel the subscription >> >> interface Foo { >> subscribe (callback :Callback) -> (handle :Capability); >> } >> >> or b) >> >> fulfil the promise returned by the method call at EOF, and drop the >> promise to cancel the subscription. >> >> interface Foo { >> subscribe (callback :Callback); >> } >> >> I'm curious to understand fully the pros and cons of each approach, >> especially when the callback is a ByteStream, where it seems natural to >> return the pumpTo promise as the result of the subscribe call's >> implementation? >> >> Cheers, >> Vaci >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Cap'n Proto" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/capnproto/790ea1e0-65e6-44e1-a97a-93e943dd8b34n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/capnproto/790ea1e0-65e6-44e1-a97a-93e943dd8b34n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/026806ab-0704-46ec-8b30-5101adb882a9n%40googlegroups.com.
