have you seen rq? for some tuplespace-like needs it'll suffice.
hi,
yeah i stumbled upon rq a year or so ago, and forgot all about it.
thanks for reminding me. only i have not the vaguest idea how it works.
the docs are quite thick and since i have *no* experience with nfs, i'm
having trouble understanding the architecture.
would greatly appreciate a sentence or two describing the basic
structure
of the thing so that the docs can begin to make a bit more sense to me.
how are the database and the nfs file system tied together, for instance
and what role does each play?
funny, because i was about to post about implementing a similar thing (i
think, but possibly it is completely different?
).
i basically need a fast, persistent, hierarchical hash, and it occurred
to
me that that is precisely what a file system is. so that if i exposed a
subset of some filesystem via drb i get pattern matching for free via
Dir.glob and friends and have a tuplespace-like hierarchical hash with
the added advantage of being able to easily distribute large files as
well.
more precisely, there would be one central process which controls access
to some file system. clients just drb (or any other communication
mechanism) into this process and can do tuplespace-like operations on it
(read write take etc). so:
cp.write 'foo/bar/haha'
would create 3 nested directories if they didn't already exist.
cp.write 'task/12/{1,2,3}'
would create directories 'task/12' followed by three subdirectories 1, 2
& 3
cp.read_all 'task/12/*' would return the paths to all the above.
you could also have xxx_file & xxx_marshal versions of read, take, write
etc which handle files with contents, and marshalled ruby objects
instead of just directories.
just like with tuplespaces all communication happens through this
central process so that we have implicit mutual exlusion, etc.
thoughts anyone?
thanks again for the tip,
christophe
