One thing that occurred to me is that the whenResolved etc. handlers only need to be customized to the degree that you want to interop with Java types that are not self-describing, such as the faked primitives and interfaces.�� Smalltalk types are uniformly self describing, allowing you to implement a single handler for all types, whereas only certain kinds of Java types are self-describing.��
If you think about it in terms of RMI, which is not really much different other than the metaphor not taking time and frequency of non-response into account, the promises and futures are much like stubs and skeletons, proxies for the remote message send and resulting method invocations/responses.�� A Smalltalk to Smalltalk interop such as SST, which is very similar to RMI, only needs one proxy for all objects, which makes abstracting it from the transport (and whether the transport is continuous etc.) much easier.�� i.e. in RMI you need pools of constant TCP connections, while in SST the�� transport needen���t be a continuous connection, it could be entirely discrete such as http, and only one abstract connection between ���spaces��� or ���nodes��� is required.
If you avoid the nasties in Java and only support interop for self-describing types, you shouldn���t need to write so much custom but rote code.�� If you do need to support non self-describing types, only on those do you need the custom rote code in the handlers.�� Further if you use only one set of proxies, i.e. one future/promise/handler set, it will be much easier to keep Raven clean and separated from the transport implementation.
If you keep in mind that although it���s a useful and powerful metaphor, the notion of futures, promises and the like is only a metaphor for invoking remote methods, which in turn is only a more mentally adhesive manner of describing remote procedure calls, with self-describing objects one handler can invoke the appropriate methods on the object by delegating the responsibility to the object itself.
Andrew
From: Pharo-users <pharo-users-bounces@lists.pharo.org> On Behalf Of henry
Sent: Saturday, March 31, 2018 3:46 PM
To: Squeak-dev <squeak-dev@lists.squeakfoundation.org>; Pharo-users list <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] Regarding Raven: DOCap System
Raven is a remote, distributed object-capability system. I wanted to stress it runs distributedly over 2048-bit encrypted ParrotTalk 3.6
Sent from ProtonMail Mobile
On Sat, Mar 31, 2018 at 15:43, henry <henry@callistohouse.club> wrote: