[E-Lang] an example impatience policy (was: remote comms)

[zooko@zooko.com]

Thanks to MarcS and Alan Karp for their thoughts on the practical needs for
impatience policies.


Here is a hypothetical example impatience policy which illustrates (for this
example, at least) the need for the "ERiaSR" comms abstraction over the
"SturdyRef/LiveRef" abstraction.


Suppose I wanted to write a turn-based board game as my first E app[1].


People usually prefer to play fast -- as little as 1 second per turn.  But since
it *is* a turn-based game, if you wait and wait and the opponent's move never
arrives, the correct behaviour is just to keep waiting (optionally: resend your
previous message in case it never arrived and *he* is waiting on *you*) until
either the message arrives or the user signals to stop waiting by clicking the
"abandon game" button.

Since it is a strategy game, it is not uncommon for a certain move to take a day
or two of thinking on the part of a player.  One of the attractions of writing
this game in E is that my users do not have to click the "save/load game"
buttons whenever they are going "off-line" -- instead persistence is the default
and you use the "create new game/abandon game" buttons instead.


So in thinking about this it occurred to me that the natural way for me (the
programmer) to communicate to the comms system that I no longer care about
messages that I sent to him is to *destroy the "game" object*!


When the user clicks "abandon game", I destroy the "game" object.  Since it was
this object that sent the messages to the other player's computer, the
underlying comms system can know that it need no longer send messages nor wait
for responses.  On the other hand as long as the user does *not* click the
"abandon game" button, then I want the underlying comm system to give me full
ordering guarantees and message retrying even if I do something like shutdown
the E runtime, unplug my laptop and stick in my backpack, etc.


It seems for this example at least that making the coder write his own 
reconnect-and-resend code in order to implement his desired impatience policy is
losing some of the gains that a persistent O-O language should offer.

It seems somewhat akin to manual persistence vs. orthogonal persistence or even
manual memory management vs. garbage collection -- asking the programmer to
manually implement such necessary features sours the promise of O-O, because it
forces programmers to descend from the mental state of "modelling the problem
domain with objects" into the mental state of "implementing some supporting
feature that I need so that I can go back to modelling the problem domain".


Regards,

Zooko

[1] (As an aside, it would be a variation of "Ogres vs. Pixies with a Carrion
  Crawler and Trees"[2].  It would also be a simultaneous-turns game, which
  would give me an opportunity to demonstrate Rivest and Shamir's "Interlock
  Protocol"[3] in action...)
[2] http://zooko.com/ogresvpixies.html
[3] http://cryp.to/publications/cryptographic_protocols/index.html#SECTION00430000000000000000