IRC channel logs
2023-05-14.log
back to list of logs
<RandyFarmer[m]>> There is one wrinkle, which is that it is sometimes useful to know when a promise is "done" resolving, which would be a bit murky if you can resolve it more at any time. <isd>Randy Farmer: not sure I follow? <isd>Ah, yeah, no, that's not what I mean <isd>Just -- at the protocol level, if you had a fully resolved thing, but you wanted to delegate handling future calls to some other thing, It seems like you could just send another resolve message, and the path shortening machinery would mostly just work <isd>the fact that you can only resolve once is afaik an arbitrary restriction. <isd>But clients would still drop the old reference when receiving the resolve, per normal <isd>The idea came up because it seems like a way to maybe implement migration. <isd>At an API level, for goblins, I imagine this could take the form of allowing you to bcom some arbitrary capability, which may be on a different machine, and then at the protocol level it would just take care of the forwarding. <isd>So, if you have alice in Vat A sending messages to a promise bob that currently points into Vat B, when bob resolves, this will cause Vat B to send a resolve message to Vat A describing what bob resolved to. Let's say he resolved to carol, also in Vat B. At this point, Vat A discards the reference to bob, and all of alice's future messages to that reference are sent directly to carol. For existing CapTP, this is where our story ends. But, suppose a <isd>servicing some methods directly, carol decides she wants to go home for the day, and let dave (in Vat D) take over. Right now, she's stuck -- she can forward messages manually forever, but those messages will still have to route through her. But, I don't see any reason why carol couldn't just (bcom dave), and have Vat B send another resolve message to Vat A, indicating that carol has resolved to dave. Then, the same path shortening logic applies, <isd>messages directly to dave. <isd>Is that any clearer? <juliana[m]>working on some code to test this out, but I'm pretty sure if an object transitions twice the existing references should still work fine so it shouldn't matter if it bcoms a different object entirely <juliana[m]>hold on, let me make sure this code is doing what i think it is... <juliana[m]>at least in Goblins, the reference points to the same object across bcoms <juliana[m]>now, if you were to instead of using bcom simply spawn a new object, that would indeed cause problems <juliana[m]>hmm, this code doesn't start with bob being a promise... let me see if i can rework it to make that the case <isd>To do what I had in mind, you'd want to change (bcom (^dave bcom)) to just (bcom dave); I'm proposing an extension that let's you bcom an already-spawned capability, that doesn't necessarily even live in the same vat <isd>where you get dave from is flexible. You could even make it an argument to transition. <isd>...with a few differences. Notably, that seems to be mainly working with immediate calls, whereas you'd need to do eventual sends since the new target may be across the network. <juliana[m]>I was just noticing that; might open a cheeky PR to use opportunistic asynchronicity :3 <isd>and it would be a little less flexible; the actor being replaced would have to do bcom itself, and then you've got a new receiver so if you want to be able to do another hop the new target has to know about it as well. <isd>But the key thing is that yeah, you don't have to maintain a proxy -- it would just redirect things at the network level and the usual "promise" machinery would handle permanently shortening the network path, so messages are going straight from vat a to vat d. <Zarutian_iPad>juliana: I try to write as asynchronicity opportunistic code as possible. Sometimes going a bit overboard. <Zarutian_iPad>like doing a conditionals in such a way to do much ?: or trinary operator kind of dataflow <juliana[m]>oh! i love a trinary operator... i also like to use or and and in Lisp land instead of if statements which has a similar vibe to me <juliana[m]>although i was reading a thing recently and i'm pretty sure there are good reasons one might want to use or and and instead of if - something about time-of-check to time-of-use? <Zarutian_iPad>on example is js`const actionp = E(E(operandA).isLessThan(operandB)).pick(actionA, actionB); E(actionp)();` <Zarutian_iPad>E being the eventual send helper thing that Agoric folks defined