We have a new RubyAMF release, 1.6.5, it fixes some bugs and improve stability. It has been possible thanks to the collaboration of the members of the group and their research, bug fixing and dedication.

For the complete list of changes you take a look at the CHANGELOG file.

You can check out this new release from the repo:

ruby script/plugin install http://rubyamf.googlecode.com/svn/tags/current/rubyamf

or

ruby script/plugin install http://rubyamf.googlecode.com/svn/tags/1.6.5/rubyamf

-Aaron

Or from the current tag:
script/plugin install http://rubyamf.googlecode.com/svn/tags/current/rubyamf

Now, for anyone interested, what was breaking was Rails 2.1’s forgery
protection, which stops cross site scripting attacks by placing a
security code in HTML and Ajax forms and verifying that that’s the
right code on the Rails side.
My fix was just to add the AMF mime type to the list of mime types
that aren’t checked for forgery protection, alongside XML and JSON. I
think it belongs there, because there’s no way that I know of to hook
into the Rails forgery protection.
To do the same type of thing from a Flash app would be a bit of a
different process, and I’m not quite sure what the best way to think
about that is, nor if it’s actually a problem we need to worry about
anytime soon. Any thoughts?
Upshot: RubyAMF 1.6 for Rails 2, RubyAMF 1.6.1 for Rails 2.1.

Cross posted from (http://groups.google.com/group/rubyamf)

If you’re not coming to the tutorials let me know if you’re coming to
the conference anyway and we can meet up and talk about RubyAMF.

Thanks again

First off, I apologize for this post being so late. It should have been about a month ago. I’m moving on from RubyAMF. It’s been such a good time talking and meeting people who supported my efforts on RubyAMF. I couldn’t say thank you enough – but I could write a loop for you.

while(true)
{
 trace("THANK YOU");
}

Put this in Flash and try it. I know you’ll love me.

Anyway. I put a ton of effort toward RubyAMF, and they haven’t gone unnoticed, it’s so cool. And I’m glad I was part of helping out make strides for remoting in Ruby.

I’m definitely not done with AMF though. Trust me . I must say AMF is by far my favorite thing to work with when using Flex or Flash. It’s kind of awkward that I’m so passionate about AMF, but it’s an amazing creation from Macromedia with so many benefits.

As mentioned, I’m definitely not done with AMF, or writing / releasing cool stuff. First off. I’m sitting on PythonAMF. It’s not ready for a release yet. I need to do quite a bit of testing yet but it will happen.

I’ve also got another version of SSR done that I will release beginning of February. It includes great new additions. Here’s a quick breakdown of the new features.

Call limiting – Turning this on puts a remoting service in a state that will not allow duplicate calls to the same remoting service if a response has not been received from a previous one. Finally, this is built in so we don’t have to have scattered logic all over to handle this. This is extremely important because you can’t risk someone figuring out that you don’t limit calls made to the server, and then they smash your server. Ouch.

Caching – If a previous request is called again, it comes from cache instead. This includes options to expire cache after a certain time or after the cache has been hit a certain amount of times.

Paging – Yeah! Now there is a paging mechanism for those flashers (or flexers) who don’t get to use remote object. Or just don’t want to use remote object. Page buffering is built in, so you can set the buffer size to say 3 pages, and anytime there is only a certain amount of local pages (which you can specify) it retrieves the buffer pages. It has an iterator like interface so it’s all taken care of. As well as allowing “releaseAll,” some might remember that from Flash 8.

Paging is also built in a way that allows you to extend the default PageResponder (which you don’t have to touch by default). But this is nice if you want to put paging on a certain remoting service call, but the results you want to page are nested within the result object you get back.

I’ve also got a custom display renderer mechanism with the same iterator like interface that allows you to use a pager, (with say 50 items per page at a time), and have an interface for only displaying 10 at a time. So it’s like sub paging on the actual pager.

I think that’s it for new features. If I think of any others I added I’ll let you know.

Another issue I’m addressing is AMF stress testing. So far I’ve only seen the Flex Stress Testing framework which could possibly be used to test AMF gateways. But the amount of users it can act as to hit the server with is pretty limited, and the tool is so overwhelming to get setup.

AMF stress testing is exactly like it sounds. Test your AMF gateways with millions of hits. This is very important when working on something that is expected to have high volume traffic. I’ve experienced numerous sites that had high volume traffic and the server side couldn’t handle it. One in particular was remoting and just couldn’t take the hits. (Not because of AMF inefficiency, but because of server inefficiency.)

So as a way of spreading the word, that we can’t just blindly put up remoting gateways for a web site and not think anything of it. I’ve come up with a very simple way of stress testing AMF.

Here’s a quick rundown of how this all works.

There are a couple tools involved. First, a “capture client”, which is a simple Flex app that you fill out your service target, method name, arguments, amf version, and if it’s remote object or not. When that request is sent, it’s sent to a local “capture server.”

The “capture server” is a ruby webrick server that takes an incoming request and writes the raw post to a file (the AMF).

The next step in the process is JMeter. JMeter is an all around stress testing tool for many different web protocols. Jmeter was the only one I’ve found so far that allows for sending a POST request with “arbitrary binary data” (from RFC1867 secion 3.3).

That’s how the Flash player sends over AMF to the server, as stated in RFC1867, AMF is just arbitrary binary. Anyway, since the AMF is just in the body, all you really have to do is send an HTTP Post request to the gateway, along with the binary captured from the capture server. And voila, you can hit the gateway as many times as you want triggering your remoting software to react and perform the same operations as what would occur when a flash / flex request comes in. This is also very important, because it’s the software you write that get’s triggered for every remoting call. We can’t just hit an index.html page and assume everything is ok, when actually none of your server software is being tested.

The other piece to the puzzle is validating response. So far I’ve been using a tool called PlasticSniffer. It’s a very simple packet sniffer that will allow you to see the requests / responses of AMF. Generally you can see the UTF data in the response, which is just some text so you’d be able to read most of what’s going on. With some awkward characters tossed in.

So Anyway, I have been very busy working on more AMF goodies and will continue to be involved with AMF. Please stand by for SSR2 and that AMF capture tool, with JMeter instructions to get that running.

I had a great time with RubyAMF. And hope to hear from all of you in the future.

-Aaron

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

Now that Rails 2 is out, you may want to know how things are working with RubyAMF and Rails 2. There was one bug breaking with Rails 2, where you would render => :amf and get an error. A fix to that error is in the development branch, and will hopefully be promoted to the trunk soon.

I’m also looking into a few other annoying bugs, which should be in the development branch soon, too.

I backed off on a ClassMapping generator I was going to write to re-write the config file with ClassMappings for each ActiveRecord. That’s now going to be a helper script that will write ClassMappings to the console for you to copy and paste and modify as needed. Non destructive, simple, and helpful.

One other generator will be a “Standard RubyAMF Scaffold” generator, which will be something like `script/generate scaffold <model name>`, but will assume that you’re only using RubyAMF and configure the generated controller accordingly.

One more generator will be the “RESTful Scaffold + RubyAMF” generator. That’s basically copied straight from the Rails 2.0 scaffold generator, but adds RubyAMF lines to the controller.

Generator scripts won’t intrude into your RubyAMF app, but they should help get your RubyAMF project up and running a little faster.