Today, without three-party handoff, you could always wrap the promise in a capability and send that. But, yes, this involves a proxy step that 3PH won't be able to optimize away later... at least not under the current design.
-Kenton On Thu, Aug 25, 2022 at 3:08 AM Vaci <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/capnproto/026806ab-0704-46ec-8b30-5101adb882a9n%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/CAJouXQ%3D86XfoRDWcwZpVq_P3MPFgLEibC5Qxsdt2Zeot9k67Mw%40mail.gmail.com.
