Plans on what to do to the code in the near (or far) future. None of these are
guaranteed to make it into the code, this is just a place to collect plans and
ideas. I might drop any of these parts if I find out they are stupid ideas or
are not really needed.

All near future plans should go into the ticketing system, this file should
only be used as a idea tank - things I am still not sure about.

far future plans:

- TupleSpaces should have their own managing thread that removes time limited
  tuples and calls registered handlers for special situations. Especially these
  threads could call registered tuple handlers asynchronously as soon as new
  tuples are inserted. Currently the tool that want's to fetch a tuple is
  blocked in that thread until a matching tuple is available. This could be
  opened up a bit by allowing tools to register for asynchronous notification.
  (This should actually be part of the event framework listed below).

- add a event notification framework based on TupleSpaces so that tools
  can register for events and can post events. This would be usefull to
  integrate TooFPy into GUI frameworks (put in a mediator between the GUI
  event framework and the TooFPy framework).

- add a RPC interface based on YAML so people could use it from Ruby to
  talk to TooFPy without the need for XML. Exceptions can't be transported
  easily over YAML, so there needs to be some other way to say "oops". Check
  up with the YAML RPC implementations already out there.

far, far away:

- replicated TupleSpace that can cross process or even machine boundaries
  so that you can use it to build load balancing or failover clusters

- additionally create a way to use multiple processes instead of multiple
  threads to make better use of multiple processor machines

