TupleSpace

The basic idea is that you can have many active programs distributed over physically dispersed machines, unaware of each other's existence, and yet still able to communicate. They communicate to each other by releasing data (a tuple) into tuple space. Programs read, write, and take tuples (entries) from tuple space that are of interest to them. A tuple-space is a public repository or buffer that can contain tuples.

http://infolets.com/1006361585/

http://www.google.com/search?hl=en&q=python+tuplespace

http://xml.coverpages.org/tupleSpaces.html

Is a Triple Store a subset? Probably so narrow a subset as to not matter much...

Rogue Wave Ruple http://www.roguewave.com/developer/tac/ruple/ article paper posting

Kimbro Staken wrote If you wanted to build an XML based tuplespace, SynCato would provide a pretty good base to build on.

Mark Baker links some discussions tying ReST to TupleSpace ideas, including this longish/thorough VanessaWilliams post.

• her followup - First, I have to come clean and admit that "RESTful tuplespace" is an oxymoron. There are probably several senses in which this is true, but the most basic is that tuplespaces violate the ReST constraint of State-Less-ness. Because of this, server Scalability is a real problem, and this is what drives the ongoing search for a viable distributed tuplespace architecture.
• others' notes connecting XPointer to it.

Some Linda notes

Patrick Logan 2002 comments

ReST parallels and Linda

David Croft background research

Dave Moffat paper

Rys McCusker said I don't like TupleSpace-s much myself, because it tastes like a manifestation of technology which attempts to promise an effect across space and time which incurs costs that go up under scaling and interference, and hide the risk of failure as the difficulty increases.

• Patrick Logan soon said TupleSpace-s are the more flexible choice vs. a Message Queue. A high performance Message Queue has network configuration options not found in the tuple spaces I am aware of. Unless very high volume messages are required to be routed among multiple subnets in selective ways, the more flexible choice is a tuple space architecture. Tuple spaces (or XML document spaces, going forward) are the 80% choice over related technologies: databases (oltp), message queues, and workflows. Only in the 20% corner cases would it make sense to go with a non-tuple space architecture.

Dave Sag CrudLet article: Crudlets as a compromise to the extreme Jini and XML communities' perspectives, as evidenced by his use of Jini-Fascists and XML geeks. Crudlets is an open source architecture essentially based on an Apache Cocoon and XSP Tag Library that maps to seven fundamental events performed by Jini agents

IBM TSpaces code and docs and paper

• A TSpaces client does not have any persistent data itself, so if it gets disconnected from a server, it doesn't have any of the server state available to it. So, if a client is "offline", it doesn't have access to any data. We're working on Enterprise TSpaces, which includes support for replicated spaces in the server. Once this is up and running, you would be able to run a client and a local server on your own machine. When you disconnect, the client will still be able to talk to the local server, and when you're online, or on the network, the local server can resolve its state with the network server.
• MoDAL (retired!) does not read from, or write to, the local PalmOS database. Mo D A L is a program that runs on the Pilot that: reads a Mo D A L program and renders the features on the Pilot screen as specified in the Mo D A L program (buttons, boxes, forms, etc); Sends and receives tuples over the network. Specifically, it speaks to a TSpaces proxy using a private protocol, that in turn translates the simple pilot messages (which aren't really tuples yet) into real TSpaces tuples. The server takes those tuples and communicates to other network services. The current implementation of Mo D A L does NOT write or read tuples in the local pilot database. So, it doesn't matter what else is running on the Pilot.
• If you just want to send and receive tuples and then write them to the local Palm DB, then you might consider taking a public package, like Rmi Lite. You'll have to do some programming, but you'll be closer to your goal. RMI Lite has a small client that allows you to send/receive tuples - it also speaks to a proxy that allows you to turn the simple Pilot messages into tuples or into RMI calls.

JavaSpaces http://www.artima.com/jini/jiniology/js1P.html