I have been looking at Python’s Twisted.  It’s a framework for writing event-driven systems.  I have built far too many event drive frameworks in my day.

One of the core abstractions in Twisted is an object they call a “Deferred.”    I really wish they had called it a Promise.  Routines that need time to gather their results  immediately  return a Deferred object.  Later they give that object a kick to signal a result.  Here’s an imaginary bit of code.  Remind_me returns a deferred that presumably will get a kick next Tuesday.

pending_reminder  = reminded_me("next Tuesday")


Back in the 1960s I learned a language called SNOBOL, a precursor awk, Perl, icon, and the amazing SL5. One of SNOBOL’s amusing features was that you were encouraged to write, for every statement, a clause to handle both success and failure.  It’s a good fit if you are doing a lot of pattern matching.

These days we use exceptions.  Every time you call a function you know that it can either work out, or it will throw an exception.  The methodical Twisted programer has to worry like a SNOBOL programmer.  But unlike SNOBOL your forced to bundle up everything in functions.  And, since Python’s lambda expressions are quite limited.

pending_reminder.callback(pay_the_bills)
pending_reminder.errback(reschedule_the_bill_payments)

These Deferred instances are, in effect, a pipe from the process working on getting your result and the party that requested for that result. The Deferred is effectively a contract between these two parties; call the two parties the buyer and the seller.  In the above example they buyer purchased his wake up call, and the seller has promised to either deliver that wake up, or to at least signal an error.

What Twisted is doing solves only half the problem.  What if I want to cancel my wake up call.  Twisted has no defined mechanism for the buyer to notify the seller that his order should be canceled.  Say I’m building a web page for the user.  I ask a number of parties to go gin up bits of that display.   Before they finish the user loses interest and closes the window.  I haven’t any way to tell the providers that they should stop.

The supply chains like this are typically more complex than ordering/wait/error, or even order/wait/error/cancel.  The more general problem is flow control.   The quality of the communication channels varies by orders of  magnitude.    It is invaluable to be able to tell the downstream provider about that variability.   An extreme case is when the user’s client goes to sleep.

No doubt these problems can be layered in on top of Twisted’s abstractions.  But, I found it discomforting that these is no way for the buyer say ‘never mind’ to the seller.