TSpaces

Guest talk by Toby Lehman, IBM Almaden, for Armando Fox's CS444I class (Spr 99)

• TSpaces hides the network: assumption is that everyone can always see the Tspace and access it.  No abstractions in the design for handling disconnection, remote queueing (client not connected when a tuple arrives for it), etc.
• TSpaces is more like Corba than it is like Ninja: it's infrastructure to allow some least-common-denominator of communication, but it's purely data driven (not imperative like Corba).  The provision of services, directories, etc is strictly outside the scope of TS.  It provides mechanism but not policy (or even mechanism whose design derives directly from policy).
• How to maintain consistency between client's tuplespace and big tuplespace?
• Is there a notion of "proactively pushing" tuples to a client?
• Scalability: is a global Tspace really what you want?  How do you manage separate Tspaces?  Is the most useful model really just a local tupleserver?
• What is the set of small-device interaction problems that Tspaces are useful for solving?  SOunds like this mechanism is really a bootstrap for other stuff which you then build on top (ie it's infrastructure).
• Java-based TS server interface: create/delete space, security, ACID transactions, tuple ops (read, write, take, scan, update in place, delete, scan, consuming scan, count...database-like ops and extensible by downloading)
• Events: trigger when a new tuple is added to the space; not (yet) when someone else reads  a tuple

Tspaces has an identity problem:

• The query template stuff is similar to Lore
• THe infrastructure stuff is similar to Ninja

Thoughts

• Thought:  NInja has done a better job of thinking about the service and path creation stuff, so maybe the right path is to mediate between ninja and Tspaces (and that also solves the political problems...)
• Today the PDA's using TS go thru a proxy.  Is there generically a Web FE for talking to TS? Can we get some Workpads for this?  What other devices are supported?
• How hard is it to write a client-side TS "native" library?  Do the lack of disconnection abstractions get in the way?  What about caching pieces of the TS on the device--do the lack of abstractions for talking about consistency get in the way?
• MoDAL - do we really care? This has been done before, and HTML is pretty darn close (if you add extensions to do local storage, etc).  One possibility: TCTM extended with ability to read/write tuples on the device and be woken up (we have to add the second thing anyway, for notification).  If we do want a universal device langauge, maybe a compiled subset of Tcl would be better?