Persistent tuplespace

hi,

just trawling google a bit i’ve found a few references to
people hacking stuff together to make a persistent rinda,
but nothing really conclusive or very solid looking.

just wondering if anyone has done any more work on this recently?

thanks,
_c

On Dec 13, 2007, at 11:09 AM, Christophe M. wrote:

hi,

just trawling google a bit i’ve found a few references to
people hacking stuff together to make a persistent rinda,
but nothing really conclusive or very solid looking.

just wondering if anyone has done any more work on this recently?

thanks,

i hacked tuplespace to be backed by sqlite and hit a few
roadblocks… it’s easy enough to do from scratch that i decided
that’d be better than layering on top of what’s there…

have you seen rq? for some tuplespace-like needs it’ll suffice.

cheers.

a @ http://codeforpeople.com/

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? :slight_smile: ).

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

On Dec 14, 2007, at 8:39 AM, Christophe M. wrote:

thoughts anyone?

99% of the work has been done for you. check out fsdb.

a @ http://codeforpeople.com/

[1] http://redshift.sourceforge.net/fsdb

will have a close look.

need to determine if i can implement tuplespace-like
semantics on top of it. even if not, the code
will be useful to look through.

thanks for the tip!

_c

ara.t.howard wrote:

On Dec 14, 2007, at 8:39 AM, Christophe M. wrote:

thoughts anyone?

99% of the work has been done for you. check out fsdb.

Also, fsdb[1] does its own mutual exclusion, both for ruby threads and
for separate processes, so it would not be necessary to bottleneck all
access through one process using DRb.

Another useful feature is that you can define a mapping from file path
patterns to handlers for different serializations. So .yml can be
treated as YAML, .mar as Marshal, and so on for .csv, .txt, .jpg, etc.

[1] http://redshift.sourceforge.net/fsdb

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs