<humanetech>
Thank you kentonv. I could see how an Actor Model could be built on top of Cap'n Proto, where you can apply different strategies if a certain (sub)actor fails to respond adequately.
yarmo has quit [Quit: Ping timeout (120 seconds)]
yarmo has joined #sandstorm
xet7 has quit [Read error: Connection reset by peer]
xet7 has joined #sandstorm
kentonv has quit [Ping timeout: 260 seconds]
kentonv has joined #sandstorm
<fr33domlover>
Cap'n Proto interface question: Suppose I want to have a method 'subscribe', allowing an actor to subscribe to some events coming from another actor. The return value of 'subscribe' would be a boolean yes/no, saying whether the actor has accepted your request to subscribe. Sometimes it's an automatic yes, but other times a human reviews the request
<fr33domlover>
hours/days later and can manually decide yes or no. Should the yes/no be in the return value of subscribe, or should it be sent as a separate method call?
<fr33domlover>
(I assume return values make sense only for stuff that doesn't need to wait days for a human to act on, am I right?)
xet7 has quit [Ping timeout: 260 seconds]
<fr33domlover>
I also wonder: If subscription is successful, should the return value contain a capability allowing to unsubscribe later? Is that intended sane usage of capability based programming? "^_^
<fr33domlover>
(the other way I see is to add an 'unsubscribe' method, but then the invoker of the method needs to somehow specify who they are...)
<isd>
fr33domlover: method calls happen over an active connection, so yeah anything that's on that time scale should not just be a return value; you'll probably have to persist & restore something to get it to work.
<isd>
"drop the handle to unsubscribe" is a common pattern, though it's not entirely clear to me how it would mix with persisting objects (kentonv, thoughts?)
<isd>
Also, I still haven't added a way to haskell-capnp to explicitly drop a capability; it just happens when the GC gets to it. Will probably happen at some point, but a close() method might be better than relying on a finalizer/dtor for the time being.
<fr33domlover>
isd: thanks for these hints! Can capabilities be serialized and restored? If yes, when I subscribe and get a Handle to drop later, I suppose I can store this Handle for use any time later? Can the system be serialized and re-launched like in Spritely Goblins, with object references remaining intact and valid?
<fr33domlover>
I imagine these may be very basic questions; if I'm being too lazy asking instead of just experimenting, tell me "^_^
<isd>
There's no support built into the libraries for this, but what's typically done is just to define a save() method or the like which returns a token, which can then be passed to a restore() method somewhere.
<isd>
It's not possible to serialize the entire connection state unfortunately.
<isd>
It's still future work to come up with a standard version of this for use on the open internet
<isd>
persistent.capnp which ships with the reference implementation defines parts of this
<isd>
Hm, looks like at some point RealmGateway was deleted from the upstream version (which I haven't pulled in yet). kentonv, was there a rationale for that? Some problem with the interface such that it wasn't workable/a good idea?
larjona has quit [Ping timeout: 248 seconds]
<fr33domlover>
isd: does the haskell canpnp library have a way for an actor to kill itself?
<fr33domlover>
Ah, I see now... I guess there's no need? because once all references are dropped, GC can just delete the actor automatically
<isd>
Right.
<isd>
But no, there's no way for an actor to shut itself down. If you want to "disconnect," the closest thing you can do is start responding to every method with a disconnected exception.
<isd>
But the object will live as long as there are references to it.
<isd>
Hm, actually, the thread will shut down if the supervisor passed to export shuts down, so you could arrange it that way. ...and I should probably change it so it starts throwing disconnected exceptions in that case; I think right now there's no logic to actually do anything with the queue if that thread isn't running...