Charles Nutter, aka @headius, has graciously offered to merge his (very successful) ruby-atomic and thread_safe gems into ours. I think we should accept his offer. He has done great work and has been an avid promoter of this gem. If we want to pursue this, we need a plan. Let's use this thread to discuss the roadmap. There are several open issues we need to discuss and make decisions about. Below are my initial thoughts, in no particular order. All input is welcome.
0.6.0 Release
As I discuss in this thread, I think we should release 0.6.0 ASAP. There is a ton of great stuff waiting to be released to the community.
0.7.0 Release Date, with Atomic
I think we should target early August for the release of 0.7.0 with ruby-atomic merged. @headius will be speaking at Steel City Ruby in Pittsburgh, PA on August 15. Pittsburgh is only 2 hours away, by car, from where I live in Akron, OH so I plan to attend (and I've submit a talk proposal so with a little luck I may be speaking, too). This would be a great opportunity to announce the gem merge and promote our work.
Assuming we target this date for the next release, what else should we include? Two things that come to mind immediately (in addition to merging ruby-atomic) are new actors and C extensions.
GitHub Organization
@headius has also suggested we create an organization within GitHub for this gem. As much as I love having my name in the URL, this has become a true team effort. The gem wouldn't be where it is today had I worked alone so I'm happy to move the repo from my personal account to an organization. If we do that, however, we need a name for the organization. Any suggestions?
One Gem, or a Family of Gems
Right now we have about 3,700 lines of code, not counting tests. We plan to extend actors significantly and also merge in up to two additional gems. Has this gem grown too large? The gem composition seems "right" to me because we have a very robust toolkit that is very nicely layered from high-level abstractions (like Async
and Future
) through mid-level tools (like IVar
) down to low-level, optimized utilities (like AtomicFixnum
). But we also have a few groups of related functionality that could be pulled out into separate gems. I'm not sure how I feel about keeping everything in one gem versus creating a small family of related gems. My only concern is excessive fragmentation. We could easily do ourselves a disservice if we create too many. One possible way to create multiple gems would be:
- Atomics
- Actors (later, once they grow in scope)
- Everything else
External Dependencies
In another thread we discusses the inclusion of external gem dependencies. We currently have none. My preference is to remain that way. My impression of that discussion is that the majority of the team agree. One result of this discussion was the offer to merge ruby-atomic into our gem. Moving forward we should have consensus on this issue.
Native C and Java Extensions
We've already added several JRuby optimizations and we recently began experimenting with C extensions. We have not made a decision regarding C extensions by my preference is to use them when they make sense. If we merge ruby-atomic into our gem we've answered our question because it has a native C implementation.
One of the greatest strengths of this gem, I believe, is that we have always been interpreter-agnostic. We have pure Ruby implementations of everything. We only use Java to optimize. Our audience is the entire Ruby community, not a subset of it. I believe we should continue with this goal and very diligently follow it.
I do not know if ruby-atomic and thread_safe have pure Ruby implementations. If they do not and we choose to merge them I believe we should update the implementations to follow the "pure Ruby with native optimizations" approach that's served us so well this far.