From sfeley at gmail.com  Mon May 24 13:40:22 2010
From: sfeley at gmail.com (Stephen Eley)
Date: Mon, 24 May 2010 13:40:22 -0400
Subject: [Revactor-talk] Some questions about Revactor
Message-ID: <AANLkTikKHjZNNlhwdhbAAta6PH_ZW_lk6qgo6Xe8rdkb@mail.gmail.com>

Hi Tony (and anyone else listening),

I hope you don't mind my brushing off some of the cobwebs on this
mailing list.  I'm working on a new Ruby driver for MongoDB -- one
that's a bit more optimized for concurrency and fast atomic updates
than the 'official' driver.  I knew I wanted to use an event-driven
model for this, because it fits so neatly with how Mongo's wire
protocol works.  My researches led me to Rev and then to Revactor, and
I realized very quickly that what you've done with Revactor is almost
exactly what I was expecting I'd have to implement to connect message
events with objects.

I've looked over the documentation (great usage and philosophy
narratives, BTW) and done some test tinkering with it in IRB, and I
_think_ I'm starting to grok it enough to start plugging it into my
real objects.  But there are a few things I'm unclear or just curious
about.  The README makes a lot of sense, but the examples were fairly
trivial exchanges with simple inline blocks and "run once, then die"
receive calls.  I understand why this is the case, but it gives me
less of a sense for good practices when constructing long-running
Actors with responses that run longer than a line or two.

Any insight any of you can give to any of the following would be appreciated:

1.) When implementing a standard "send/reply" message cycle, is there
a method for the receiver to find out who the sending Actor is other
than having it pass itself as part of the message?

2.) When running a "receive loop" (i.e., making the same receive {}
call over and over) are there any shortcuts to get around creating a
new filter and re-registering the same procs in it every time?  This
seems fairly inefficient, given the overhead of object creation and
collection in Ruby.  It'd be great to be able to either pass in an
already-existing Filter object that could be reused, or else loop the
receive block somehow without leaving its scope.  (Which would mean no
return values, but that's fine -- a "service" Actor like this would
just send out messages instead.)

3.) What is the purpose of the "dictionary" (the built-in hash and
[]/[]= operators) on every Actor, and how does it mesh with the
statement in the Philosophy document about "message passing as the
only means of exchanging state?"

4.) Delicate question here...  It's been a long time since the last
Revactor update on Github.  Is this still a "living" project?  From
your own usage of it, would you consider the 0.1.5 release robust
enough for use in other production-capable libraries?  Are there any
known issues I should know about?  (The answer likely won't stop me
from using it, and/or forking and maintaining it as needed.  I'm
excited about it; I just don't want to be caught by surprise.)

Thanks very much for your time.  I'll keep you posted on how the
driver goes -- I want to have _something_ out in the world within the
next couple of weeks.  >8->


-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org