One of the "ToDo" items was to create a way of cancelling a
subscription in progress, as people (somewhat) frequently fall into
the "hole" of having some attempt at a subscription in progress for a
while, which then keeps breaking, and which then blocks anything else
from happening on that node.

Here's an outline of an approach to the issue; if you see holes in
this, feel free to comment...

What we thus do is to create a new Slonik command, CANCEL
SUBSCRIPTION.

  cancel subscription (id=2, receiver=4, event node=3);

This command will inject a CANCEL_SUBSCRIPTION event at event node #3
which will cancel any SUBSCRIBE SET events for set #2 on node #4.

1.  SUBSCRIBE SET event "hook"

We would then add a "hook" at the beginning of the code that detects
SUBSCRIBE SET events; this hook would search the provider node to see
if it has any CANCEL_SUBSCRIPTION events for the set in question that
are newer than the present SUBSCRIBE_SET event.  If that be the case,
it would not bother performing anything further of the subscription.[1]

There wind up being two possibilities:

- Supposing the SUBSCRIBE SET wasn't yet in progress when the CANCEL
  SUBSCRIPTION request came in, no (further) attempt would be made to
  set up the subscription.  Perfect!  That's exactly what we asked for.

- Alternatively, it is possible that the SUBSCRIBE SET request may
  have already completed.  If the subscription was in progress at the
  time that the CANCEL request came in, there isn't much of a way (short
  of polling periodically inside the code that processes this) to force
  cancellation.  One might force this by signalling the slon with
  SIGTERM/SIGKILL; when it restarts, the re-attempt to process the event
  would take us back to the first case...

  ... But absent of that, the subscription may indeed complete.
  We nonetheless need to eliminate the subscription as other nodes will
  likely by this time have been informed of the elimination of this
  subscription.  [2]

  Thus, we need to perform the equivalent to "UNSUBSCRIBE SET" at that
  point.

2.  SYNC event "hook"

We'll wind up needing a similar hook in SYNC to what's in SUBSCRIBE
SET, I think, so that if there is an outstanding CANCEL_SUBSCRIPTION
for the local node's subscription, we arrange to do the equivalent to
"UNSUBSCRIBE SET".

3.  CANCEL SUBSCRIPTION event

On the node where the set is, this will either be a NO-OP, if the
subscription is already cancelled, or this will do "UNSUBSCRIBE SET,"
as with the earlier hooks on SUBSCRIBE SET and SYNC, if it is still
active.

On nodes other than the receiver node for the subscription, the CANCEL
SUBSCRIPTION event would perform the equivalent to "UNSUBSCRIBE SET"
to indicate the cancellation of the subscription.[3]

Footnotes: 

[1] Note that if someone accidentally submitted a whole series of
SUBSCRIBE SET requests, it only takes ONE request to CANCEL
SUBSCRIPTION to turn them all into NOOPs.

[2] Note that we can't simply say "Oh, the subscription *DID* work,
we'll keep that!" as the effect of CANCEL SUBSCRIPTION will have been
to drop info about the subscription from other nodes.  We *must* kill
off the subscription even though it might have worked.

[3] Open question: Should the CANCEL SUBSCRIPTION event wait until its
location in sequence to be processed on the other nodes (e.g.  - nodes
other than the specified receiver), or should we have it invoked via
the hook in SYNC?  I'm not certain...
-- 
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://cbbrowne.com/info/sap.html
"...Yet terrible as Unix addiction  is, there are worse fates. If Unix
is the heroin of operating systems, then VMS is barbiturate addiction,
the Mac is MDMA, and MS-DOS is sniffing glue. (Windows is filling your
sinuses  with  lucite and  letting  it set.)   You  owe  the Oracle  a
twelve-step program."  --The Usenet Oracle