Titus Brown wrote:
> [ apologies if this seems OT; just yell at me and we'll move ;) ]

Me too.

[much snipped]

> -> I've considered having the agent process, which communicates with the
> -> tuple space, spawn a second process to do the actual work. If anything
> -> is going to die, my reasoning goes, it will be the heavy-lifting
> -> process. If that process doesn't return an OK to the communications
> -> process within an expected time, then the comms process could push the
> -> job's tuple back into the space, and perhaps kill itself. Essentially
> -> it's a "rollback on timeout" in a long-running transaction. I don't have
> -> a whole lot of heavily synchronized stuff going on, so this is about as
> -> transactional as I would need to get.
>
> I have toyed with this idea, and will probably do this.  It would more than
> quadruple the amount of job-generic code running on the client, though,
> and I've held off because of that.  (OK, OK, quadrupling 10 lines isn't
> so serious...)

Too funny! ;-) It does seem to be a reuseable pice of code, though: one
script to run a "generic agent", maybe a config file to tell it what
tuples it can ask for, and which scripts to spawn in response to those
tuples. Not *too* bad...

>
> -> I'm a bit leery of my ideas, and that's why I'm sharing them with you;
> -> feedback is most welcome! The whole tuple space idea is clean and
> -> elegant, and my ideas are messy and roughshod. I feel like a Visigoth
> -> draping bearskins in the temple of Pallas, to make it feel more like
home...
>
> I just try to be an effective Visigoth these days ;).

There's a Python slogan in there somewhere. ;-)


> -> I really would like to leave the door open for agents to be written in
> -> any language (though certainly in Python for the near future), so Pyro
> -> might be a step in the wrong direction for me. And I'm really taken with
> -> the simplicity factor of tuple spaces. If I can write or find a more
> -> efficient implementation down the road, it should be relatively easy to
> -> integrate into my other work, since the tuple-space semantics (and API)
> -> should be almost unchanged.
>
> There might be room for a Web services-style implementation; your project
> sounds interesting!  OTOH tuple spaces are *so* simple that unless you
> really solve a hard problem... well, you get the idea.

+1. I'm using an HTTP interface for now, again maybe as a stopgap but
it's good enough for today.


> If you have any references you have found useful, I'd be interested in
> them.  I didn't even realize JavaSpaces existed; heck, I built the system
> before I had ever heard of a tuple space...

IIRC, it all started with Carriero & Gelernter's paper, "Linda in
Context", so that's would make some good reading:

    http://portal.acm.org/citation.cfm?doid=63334.63337

Apart from Linda, the two tuple space implementations I'm familiar with
are Sun's JavaSpaces and IBM's TSpaces. JavaSpaces was part of the JINI
project, which is 'old tech' as far as buzzwords go, but there's still
lots of documentation (including a community site, http://jini.org ).
The "JavaSpaces Service Specification" is short, is more about tuple
spaces than about Java, and cites some interesting articles.

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

IBM TSpaces had some good reading and documentation, IIRC. They have
published a number of papers at:

     http://www.almaden.ibm.com/cs/TSpaces/papers.html.

"JavaSpaces: A Distributed Computing Model" is a nice short paper
highlighting a few synchronization and communication patterns.

     http://www.cs.helsinki.fi/u/campa/teaching/manel-final.pdf


-- Graham