Jason Sibre wrote:
>>Graham Fawcett wrote:
>>
>>>Actually, it would be very interesting, and probably quite simple, to
>>>write a Quixote-based tuple space engine: a bare-bones write/take
>>>interface with a pluggable backend (in-memory, ZODB, Berkeley, ...).
>>>Would anyone be interested in such a thing?
>>
>>I couldn't resist.
>>
>>For your amusement, attached is a trivial tuple space
>>implementation, built using Quixote and Medusa.

> Thanks for posting this, it made for an interesting read, and I got some
> ideas from it that should be useful.  As I was reviewing it, I wondered
> about the wisdom of using eval() and repr(), but I saw after re-reading the
> above that you were well aware of the concerns.  I guess you did it that way
> because of the simplicity, and ease of debugging while you wrote it...

You're welcome, and you're right. I didn't want to spend a lot of time working
out encoding/marshalling when that wasn't the point of the example.

> Got me to thinking about XML-RPC, pickle, etc, and other issues:
>   Using something like this would require that the agents responsible for
> doing the work (running queries, etc) poll the tuple space at some interval
> to detect the presence of tuples that they're interested in.  Is there a
> provision in the concept of tuple spaces for a subscriber agent that wants
> to be notified of insertion of tuples matching specific criteria, or is that
> outside the bounds of responsibility of a formal tuple space?

I'm not an authority on tuple spaces. But my understanding is that a formal
Linda system supports only writes and takes. However, some "Linda-like"
implementations, notably JavaSpaces, have included a 'notify' mechanism that
does exactly what you've described. JavaSpaces also defines 'leases', whereby
entries are "garbage collected" if they are not taken before their expiry date;
and I'm sure it does some other neat tricks as well. See the JavaSpaces Service
Specification for more info:

   http://wwws.sun.com/software/jini/specs/js2_0.pdf

It's worth remembering, too, that HTTP is probably not the optimal protocol for
tuple space communication, esp. on a single host or a LAN. A high-performance
implementation might block on a 'take' command until a suitable entry was
written into the space. I imagine that blocking sockets would be more efficient
than repeated queries (i.e., query once to the space, and block indefinitely
until the space responds; and it won't respond until a suitable query-match is
available). In this model, you might not need a callback; just leave your query
open until the result appears.

If you are interested in playing with this HTTP-based implementation, and you
want to implement a subscription interface, you might consider looking at the
HTTPEvents work-in-progress spec, part of the writings on the REST
architecture. Just for ideas, of course.

   http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents


> Thanks for the ideas,
>
> Jason Sibre

Best wishes,

-- Graham