Hello Chums,

I wanted to give everyone an update on where RubyAMF is right now.

Aaron started RubyAMF over a year ago, and he put a lot of long hours and hard work into it. A few months ago Aryk Grosz from Mixbook.com helped out with a lot of speed enhancements. We need to give mad props to these guys for  all the work they put in. Also, to everyone else who’s submitted patches or filed bugs, or, like Peter, written about RubyAMF.

I’ve spoken with Aaron about where things are going, and he’s pretty burnt out and he’s interested in moving on to some other cool projects he has in mind. It’s sad, but he’s done a lot, so no one can fault him.

Where does that leave RubyAMF? Well, in your hands.

I’ve been interested in RubyAMF for a while, and I’ve slowly come to understand how things work, but I’m certainly not as smart as Aaron, so the best I can do to help RubyAMF is to put out a call to action.

RubyAMF is a going to be a community effort. It’s not like we need to write it from scratch, but there are some important things that need doing to make sure this project is the best it can be.

Here’s what I’d like to propose as the set of values for the plugin (in order):

Measurable Goals
1.) Stability
2.) Implementation of the AMF specs (AMF3 and AMF0)
3.) Speed

Subjective Goals
4.) Invisibility
5.) Good Development Workflow

The last two are subjective because different people will see these goals being met differently. Invisibility means that the plugin should be as easy to use out of the box as possible, while meeting the other goals. It should also stay out of the way as much as possible during execution. Offering a good development workflow is a nice to have, and the lowest priority, but it’s still nice to have. Things in that heading are generators, ease of configuration, and the power to do more complex things when necessary.

To meet these goals, we need a few things. We need participation from the community in these areas:

– Tests
We need testing of all parts of the framework from serialization/deserialzation to rails integration. Test::Unit? Rspec? Mocks or no mocks? I don’t know. We need these early so that we can measure the stability of the plugin against patches or enhancements.

– Benchmarks
Speed is important, especially since we’re working with a dynamic language and a framework like Rails that favors development workflow over raw speed. We need benchmarks to enable us to have measurable landmarks for conversations around speed.

– Bug Fixes
Once we have the above, it becomes a lot easier to accept submissions, or more importantly reject them with solid reasoning and a goal to shoot for. Submission breaks a test? it gets rejected. Submission works but slows us down? try again.

– QA
Anyone using RubyAMF who finds a bug and files it helps.

– Development Enhancements
The nice touches that make it easier to work with RubyAMF.

– Documentation
Of course it should work out of the box, and have good documentation in the config (it does), but we could use some tutorials, some walkthroughs, some complex use cases.

Marketing (just kidding)

So, I suggest if you can help in any way post on here. I’m busy too, but I’ll try and help get this effort into shape. I’m not going to say I have the power to deny anyone into the project, but hopefully everyone can get into the action. The best community code projects work when people who put in the time and effort and show good results surface around areas of the project – in this case around the areas that I mentioned above. It will take a little time for that to happen, but until then we can work as a group to discuss the merits of any descisions that need to be made.

So.. that was a long post, but that’s the state of the community. If anyone interested steps up we can start to talk about where the code is.

Thanks a lot guys!

-Tony