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
--
Posted via http://www.ruby-forum.com/.
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.
On Dec 13, 2007, at 11:09 AM, Christophe Mckeon 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,
--
share your knowledge. it's a way to achieve immortality.
h.h. the 14th dalai lama
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
--
Posted via http://www.ruby-forum.com/\.
99% of the work has been done for you. check out fsdb.
On Dec 14, 2007, at 8:39 AM, Christophe Mckeon wrote:
thoughts anyone?
--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama
ara.t.howard 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] FSDB
On Dec 14, 2007, at 8:39 AM, Christophe Mckeon wrote:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
[1] 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
--
Posted via http://www.ruby-forum.com/\.