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.

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!