IRC channel logs

<av0n>hi all! I was wondering how OCapN would work between one actor system that has promises, and one that only has an async "fire and forget" messaging model? Been working with the Syndicate project a lot recently and figure it would be cool if the two systems could interact, but not quite sure what this would look like.

<Zarutian_iPad>hmm

<av0n>syndicate for reference -> https://syndicate-lang.org/

<Zarutian_iPad>fire&forget as in no answer back unless via an cap given in args or just no promise pipekining?

<dthompson>you kinda need promises

<Zarutian_iPad>pipelining*

<Zarutian_iPad>the first is basically op:deliver-only messages

<av0n>as in no answer back, like each function call doesn't have a return

<av0n>yeah it's like only supporting that op, but I think handoffs and stuff might require more?

<Zarutian_iPad>well you might want to have conventions on the syndicate side for how to speak with things that expect invocations via op:deliver

<Zarutian_iPad>you could fake it in the comms system impl to support 3rd party handoff and all that

<av0n>hmm yeah okay, I think on the syndicate I could probably build up a request/response system.

<av0n>so that actors responding to messages could choose to tie the response to the incomming message

<Zarutian_iPad>in uFork (see uFork.org ) we often use 'customers'

<Zarutian_iPad>basically you give in the args a capability that designates who should get the response

<Zarutian_iPad>sometimes there are two, one for normal 'return' and one for errors

<av0n>oooo interesting ty! uFork looks very cool

<Zarutian_iPad>like in twisted python where you give a callback and errback

<Zarutian_iPad>or in .then in js promises the callback and errback closures

<Zarutian_iPad>you loose out on promise pipelining though

<av0n>yeah true

<Zarutian_iPad>or at least until I can figure out how to do promises via actors

<av0n>I think this idea should be enough to at least get some sort of primitive syndicate <-> goblins communication going though!

<Zarutian_iPad>as you could make a trio of actors: a promise (basically a forwarder awaiting) and the callback and errback customers

<Zarutian_iPad>the last two, via facet convention tell the promise what the call that instigated them resolved to

<Zarutian_iPad>then the promise can forward whatever normal invocations it had stored up

<Zarutian_iPad>and if that trio is made such that they can work with the ocapn captp comms system then the promise can foward those normal invocations immediately

IRC channel logs

2025-01-17.log