Guest talk by Toby Lehman, IBM Almaden, for Armando Fox's CS444I class
- 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
- 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
- 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?