Plan 18
I wanted to record this evening’s insight stemming from dinner with Markm.
The least demanding requirement for a bank keeper may be as follows.
When the bank cannot perform some normal request, presumably to buy material, it keeps the resume key of the requester while it calls the keeper.
While the keeper runs the bank is waiting and unavailable.
Banks with keepers are not promised as prompt.
I think that some of the above pages assume more stringent requirements.
When I am more awake I will research this.
(2017) The ideas below fail for it must be impossible for other clients of the kept bank to call it for buying pages.
Another unexplored idea is that the bank calls its keeper and the resulting resume key may be called, as a bank, to sell stuff.
Presumably the idea is that the keeper will call dispensable objects with an order code to delete themselves.
Those objects have been programmed to keep the bank whence they came to sell stuff back.
That is probably the very bank that is busy!
That idea is too heavy for this context.
The keeper must not be trusted with the original resume key lest the untrusted keeper return bogus pages or nodes.
(2016) It just now occurs to me that the bank might fork its keeper passing the return key for the requester.
This makes the bank available again so that someone the keeper signals can sell pages back to the bank, or take other actions to fix the situation.
When the keeper is thru it can return to the return key.
There are at least two advantages of the keeper pattern:
- Most invocations of the kept object avoid extra messages.
Admittedly the exceptional cases must be tested for but this was already necessary in the extant uses of this pattern.
- More fundamental, the kept object may be trusted by its user more than the user trusts the keeper.
Even a kept bank can vouch to a user that the pages are clean and private.
The keeper is not in a position to break that agreement.
It might be possible for bank code to allow some keepers RO keys to the pages.
In this case the validity test for banks would have to reveal this extra keeper power.
I suspect this function is better done somehow without the keeper pattern.
(2016) It is important to show that the keeper can offload bank complexity and run with less authority.
If the keeper gets only the return key to the blocked bank customer then this goal seems satisfied.
This keeper key needs to be included into the factory’s special bank logic.
Is it possible that a muffler on the keeper key might suffice sometimes to limit bandwidth from a confined calculation?