I just put up another version of Plugout which has one minor change for Leopard. When starting a browser from Plugout, you would get an NSQuickDrawView deprecation warning. NSQuickDrawView is part of Cocoa and has been deprecated in favor of Quartz. So, no huge changes – just some output redirects when starting the browser. You can see the output if any in ~/plugout_plugins/output
If you’re by any chance going to Rails to Italy. Check out Peter Armstrongs’ speach, there will be a (short) RAMF plug. Thanks Peter!
Surprise! RubyAMF 1.3.5 is under way, and no 1.3.4 will be released.
So here’s the scoop. Aryk Grosz from MixBook contacted me about using RubyAMF and some experiences he was having. RubyAMF would start to slow down with large complex data structures even slower than WebORB depending on the size, Yikes! Aryk had put time into optimizing RubyAMF and you would not believe the results we’re getting.
I went down to Mixbook in San Jose on Sunday and spent a little time with Aryk ripping apart RubyAMF. So we’ve pretty much re-written RubyAMF, here’s a brief rundown of what’s going on.
First let’s talk restructure. We ripped out 60% of the code base which was legacy from RAMFL. I won’t go into the gory details but we’ve re-arranged a lot, changed a lot of names. For example ValueObjects are now ClassMappings. Which is more appropriate because RAMF has full class mapping support. We’ve also put an init.rb file in the plugin so all the requires get done on application startup.
There are a couple other features we’ve added to class mapping definitions, such as the :associations, :attributes, and :ignore_fields properties. The :ignore_fields is just like it sounds, for a specific class mapping you can ignore specific properties on it. You can also define a global ignore fields like so: ClassMappings.ignore_fields.
The :associations and :attributes are for performance reasons. You aren’t required to use them, but if you do it speeds up the serializer even more. We’ve also change the names of :incoming / :map_to / 
utgoing to :actionscript / :ruby.
Performance! This thing is about 5x faster. As an example, a data structure of about 1500 objects that’s used in Mixbook takes around 35 seconds with WebORB. RAMF averages 2.4 seconds. Sweet! You can even see the speed increase on one object. It’s that much faster.
We also decreased the size of the data transfer. As an example, let’s say an AMF message was 250K, it would now be about 100K. That’s a huge difference.
That’s just a small preview of what’s going on. Sorry for the inconvenience of not getting 1.3.4 done last week, but as soon as we started these changes and optimizations – 1.3.4 was obsolete.
So hats off to Aryk for the help, he did a most of the speed optimizations and has been refactoring and writing a ton for RubyAMF. Thanks for the help!
And to top it all off, RubyAMF will have it’s first “in production” customer over at MixBook. They’re working on re-factoring their rails app to use RubyAMF. Awesome!
-Aaron
I just discovered that the SSR page on RIAForge is gone. Looks like a DNS issue. The new official place to read about it is on osflash.
Just in case you’re not on the mailing list. I sent out a 1.3.4 Preview release announcement. Read it here.
Just wanted to give everyone a heads up that I no longer test for Flash 8. The core features are still there, but I don’t test in Flash 8. I think we’re beyond it now.
To whet your RubyAMF appetite a little more. We’ve added in a new feature that will be in 1.3.4. This new feature allows you to map incoming remoting parameters to to params[:] hash how ever you like.
As a quick example, let’s say you wanted to map the “id” property of a “User” object to the params[:id] key. Here’s how you’d do it.
Here’s an example actionscript remoting call:
service = new RemotingService("...","UserController",3);
service.destroy([myUser],result,fault);
And the supporting RubyAMF configuration to accomplish this mapping:
Parameter::Map.register({
:controller => :UserController,
:action => :destroy,
:params => { :id => "{0}.id" }
})
This is a big improvement over the old way, which would only map the first parameter into the params[:] hash, you can decide what gets put where.
As another example. If you wanted to map the 3rd arguments “firstname” property to “params[:firstname]“. You’d do this:
AS:
service.myaction([...,...,thirdObject],result,fault);
Config:
Parameter::Map.register({
:controller => :UserController,
:action => :myaction,
:params => { :firstname => "{2}.firstname" }
})
As mentioned, this will hit in 1.3.4. Hope it’s useful 
-A
Checkout this nice tutorial. Get started with Flex and RubyAMF! Thanks Bryan!
We’ve decided to move everything to Google. The project hosting, and mailing list.
Here’s the Google Code Project.
Here’s the Google Groups.
Because RubyForge is down right now I haven’t had a change to get the source code into the repository. As soon as rubyforge is up again I’ll be moving the source there.
We wanted to move the project to google because of the features and how easy it is to use. So if you’re not already signed up on the google groups, go check it out. I also put a subscribe form down on the lower right navigation.
We’ve all been working hard to bring to our loyal consumers of rubyAMF some juicy morsels of delight. Included in our next release we’ve got such features as :through support, setRemoteCredentials, proper has_many model returns , and as Tony pointed out, camel to snake object conversion and a proper testing framework. We also plan on fixing rails magic fields problems. Killer 7-Hit Combo…Magnificent!
