We don't really have a repo for the recognition bit unless you want to stick into "ball of light". Until then, I'll gather my musings here.
I have looked at EvenMachine and while I think we could make it work, we're not really playing to its strengths. I envisioned using its queues to pass messages back and forth and attaching one bit to the standard input. Honestly, that seems like we're using stuff around the fringes.
What we're really looking for is something that can manage Actors. We don't have a web scale I/O problem. A few hundred actors would be a pretty big moment for this library.
So I started looking at Celluloid and I think that's a much better fit for where we need to go with this. With Celluloid, the only challenge is a setting up an efficient pub/sub system. I think it is going to need something like:
- Efficient pub/sub so actors can easily sign up to receive certain message types
- Basic message class so that we can implement stuff like time to live on a message. This should prevent the system from falling over if it starts to sag.
Argue with me or come up with a name :).
We don't really have a repo for the recognition bit unless you want to stick into "ball of light". Until then, I'll gather my musings here.
I have looked at EvenMachine and while I think we could make it work, we're not really playing to its strengths. I envisioned using its queues to pass messages back and forth and attaching one bit to the standard input. Honestly, that seems like we're using stuff around the fringes.
What we're really looking for is something that can manage Actors. We don't have a web scale I/O problem. A few hundred actors would be a pretty big moment for this library.
So I started looking at Celluloid and I think that's a much better fit for where we need to go with this. With Celluloid, the only challenge is a setting up an efficient pub/sub system. I think it is going to need something like:
Argue with me or come up with a name :).