Clay Karmel wrote:
Hey Rob,
What's the difference between tuple spaces and a relational database (Particularly one with stored procedures)?
It may seem a non-sequiter, but database people refer to their schema in terms of tuples.
Or else I'm just confused. It's happened before.
Clay
Clay,
I forwarded this to the list so we can all benefit from discussion in this area. I do hope you don't mind.
As far as I know, and correct me if so, a database engine has 1) a storage mechanism, 2) a transactional mechanism with mementos, 3) a naming mechanism to label things, and 4) a query mechanism to do set operations. Entries in formal relational theory is set based and tuples are the ordered sequential entities which are acted upon.
This is probably very close in theory to Linda, although there are differences. Linda isn't necesarily hierarchical in it's organization principle; the right abstraction is that tuples are ordered, sequential entities you can store in sets. Furthermore, they are stored in operational states. The current primitive operations are write, read, take, scan, and eval. There is an optimization to partition the tuples into arity categories. It is mutex protected and forks processes for eval and is blocking, or not, on query operations. This is enough to support 2).
It also has a matching algorithm, whenever an operation occurs. This means that whenever a write occurs, Linda checks for blocking reads and takes, and unblocks them if there is a match. Also, when a read, take, or scan occurs there is matching against the existing writen tuples. This matching algoritm is quite interesting as it does associative matching. Thus, instead of naming things, it is actually doing either a value comparison, or a type comparison (type ~ value or type ~ type), or it executes a filter block so you can supply your own assoiativity algorithm. Finally a field may be an eval field, thus Linda would execute the block asynchronously, and replace the block with its return value in the tuple. This is enough to support capability 4) above. Capability 3) is kind of intrinsic to the associativity matching. You could store named fields and do queries based on that property and thus, you could implement a relational database in Linda. One thing missing at the moment, aside from performance considerations, is a storage mechanism #1. Pointrel looks kinda interesting for this, although I haven't dug too deeply.
Rob
PS, I wouldn't mind seeing this go into core squeak if it were to be deemed stable enough. It isn't very big and it would be very nice as a service manager. Again that performance thing.
squeak-dev@lists.squeakfoundation.org