So, I guess here’s the obvious. SSR is a small AS3 remoting library. Stands for “Super Simple Remoting” because it’s simple. My goal when writing it was to make one library that works in Flash and Flex and handle logic that should be in every application. Personally I like using this in both Flash and Flex because I don’t forget how to use it. I always forget how to use RemoteObject so this makes a standard library for either.

So here’s an example of a bare minimum setup of SSR to make a remoting call.

import com.niarbtfel.remoting.RemotingConnection;
import com.niarbtfel.remoting.RemotingService;
import com.niarbtfel.remoting.events.FaultEvent;
import com.niarbtfel.remoting.events.ResultEvent;

var rc:RemotingConnection = new RemotingConnection("http://localhost/myGateway",3);
//gateway
//3 is the amf format

var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
//rc is the remoting connection to use for this service
//"MyService" is the service target on the server.
//4000 is the amount of time a call waits before retrying the call.
//3 is the amount of retries to attempt per call.
//true turns on call limiting, which means that the same exact call can't be made while one is waiting for a response or timeout.

//callbacks for calls, keep reading.
function onr(re:ResultEvent):void{}
function onf(fe:FaultEvent):void{}

//callbacks for calls, keep reading.
function onrArgs(re:ResultEvent,args:Array):void{}
function onfArgs(fe:FaultEvent,args:Array):void{}

rs.myMethod([],onr,onf,false); //make a call
//[] = call arguments
//onr is the result callback
//onf is the fault callback
//false - don't return the original arguments sent in the request to the callback functions

var mym:String = "myMethod";
rs.apply(mym,[],onrArgs,onfArgs,true); //make a call
//[] = call arguments
//onr is the result callback
//onf is fault callback
//true - return the original arguments sent in the request to the callback functions

This is the simplest form of setting up flash remoting with SSR without any event listeners on the RemotingConnection or RemotingService. Events for RemotingConnection and RemotingService are documented in the class files. You get events for things like disconnects, retries, timeouts, etc.

Each RemotingService can have a timeout specified for each call going to that service, as well as a maximum attempts allowed per call. If one call is made, but doesn’t receive a response within the timeout specified, it’s tried again. This happens over and over until the maximum attempts is reached, and a timeout event is dispatched.

RemotingService has an option to turn on call limiting. Which makes the remoting service smart about what to call and what not to call. If you made a call to “MyService.myMethod” with parameters ["something","something else"], it would not let you make that same call until the first one has completed, or has timed out. You’d still be able to make calls to any other service method.

Another new feature is caching. Say you make calls to some service numerous times, but the data is always the same. Instead of doing that you can enable the service to use caching. Here’s a snippet from above with caching in place:

var rs:RemotingService = new RemotingService(rc,"MyService",4000,1,true);
rs.remotingCache = new RemotingCache(-1);
//-1 specifies that the cache should never expire. (supply a time in milliseconds for an expiration if needed)

Now every call made through this remoting service will be cached. If the exact same call is made, the results are pulled from cache instead.

SSR also has paging built in with a RemotingPager. Here’s a snippet on how that works:

import com.niarbtfel.remoting.RemotingConnection;
import com.niarbtfel.remoting.RemotingService;
import com.niarbtfel.remoting.events.FaultEvent;
import com.niarbtfel.remoting.events.ResultEvent;
import com.niarbtfel.remoting.paging.RemotingPager;
import com.niarbtfel.remoting.paging.PageResponder;

var rc:RemotingConnection = new RemotingConnection("http://localhost/myGateway",3);
var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
var rp:RemotingPager;
var pr:PageResponder // just to include in compilation

var totalRecordsOnServer:int = 400; //should come from server instead.

//callbacks for calls, keep reading.
function onrArgs(re:ResultEvent,args:Array):void
{
  rp = new RemotingPager(rs,"myMethod",PageResponder,["someParameter"],re.result as Array,totalRecordsOnServer,50,2,1);
  myButton.addEventListener(MouseEvent.CLICK, onbc);
}
function onfArgs(fe:FaultEvent,args:Array):void{}

function onbc(me:MouseEvent):void
{
   if(rp.hasNext())
   {
     trace(rp.next());
   }
   else
   {
     trace("no more pages");
   }
}

rs.myMethod(["someParameter",0,50],onrArgs,onfArgs,true); //make a call to get the initial data.
//0 is the offset
//50 is the pagesize

In this example, a remoting pager is created in the result callback of the first call. A remoting pager needs at least the first page in order to be created. The RemotingPager takes care of “pre-fetching” pages with buffer options. In the above example, where the RemotingPager is created, 50 is the pagesize to grab, 2 is the amount of pages to buffer / pre-fetch. And 1 is the amount of pages that are left in the buffer before triggering another buffer fill / pre-fetch. This is the simplest form of paging, but the RemotingPager has methods for getting certain pages, getting them all, seeking, etc.

UPDATE: I forgot to mention RemotingService.MaxTimeoutsBeforeHault.

With RemotingService.MaxTimeoutsBeforeHault, you can control how many timeouts are allowed from any call, before all remoting calls are stopped. Here’s a snippet:

RemotingService.MaxTimeoutsBeforeHault = 3;
var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
rs.addEventListener(CallEvent.SERVICES_HALTED, onch);
function onch(ce:CallEvent):void{}
rs.myMethod([],onR,onF,true);

When you set this property, any call that causes a timeout, is kept track of, and if 3 timeouts happen from any call, no other remoting calls will be made. Each attempt after the services are halted, dispatches the CallEvent.SERVICES_HALTED event.

In conclusion – SSR gives you logic out of the box that should be available anytime we are using Flash Remoting. And gives you numerous other features. SSR 2 is documented very well in the source files.

In case any other AMF projects are interested in how we did this – I’ve extended the byte array documention here. I also put up a code example.

We’ve also changed how you receive them in your controller action. Previously you’d get string of bytes. But now we’re giving you an actual array of bytes. A byte array .

I don’t have any intention of writing byte array support into the serializer (send byte arrays back to flash from rubyamf). Anyone have any good use for this?

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

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

First I’d like to officially welcome Seth Tenenbaum to RubyAMF. He started helping quite a bit and his efforts are so much appreciated.

Next is some project maintenance and installing some software to work better for future developers and community. I’ll be moving SVN over to my dedicated server. The SVN move is for a new Trac install.

I changed the forum install to phpBB. And of course the wiki is being neglected for work on RubyAMF. You can still access the old wiki here.

And I’m sure some are wondering about the next release. We’ve got a pretty short bug list, but the bugs are critical. Once those are all fixed 1.3.4 will be released. Seth, Tony, and myself are working on bug fixes and feature additions.

Hang in everyone! I’ll officially be back from vacation on the 8th to release 1.3.4 and gear up for the next dev tasks. Additionally I don’t see any major conflicts with RubyAMF and Rails 2, as there is only one entry point into Rails (aside from the rubyamf controller).

RubyAMF is getting to the point where it’s a great experience tying it in with Rails (and of course with Lite) – the fact that it works with scaffolding and in your controller with render :amf makes it a winner for me. But if people don’t use it because they can’t read the site then it’s time for an update. I love working on RubyAMF so I want everyone to have a great experience with it. Maybe this sounds weird – but I LOVE remoting. The first project I did with remoting was with MercuryCloud and Patrick Mineault. Ever since then it’s been a key part of almost every project I build. So I’m not trying to be pushy about RubyAMF at all, just know that everything I put into RubyAMF is pretty carefully thought out for performance factor and ease of use.

What do you think, time for a re-skin or color update?

• Any objects properties whether it be a basic object, or value object get merged into the params hash. ONLY the first parameter gets merged though.
• Any incoming value object also gets put into params[:classtype]. So if an incoming VO is of the type “vo.Event”, it will be put in params[:event]. This will enable you to fully use scaffolding without adding is_amf conditionals.

So what does this mean? If you send parameters correctly from Flash, there are only a few updates to get everything working correctly on the rails side. Here’s a generic example that should translate to a real working example.

RAILS:

class MyService < ActionController
  def update
    user = User.find(params[:id])
    if is_amf
      u = user.update_attributes(:name => params[:name], :email => params[:email])
    else
      user = User.find(:id)
    end
    if u
      render :amf => true
    end
  end

  def create
   if is_amf
     user = User.new({:name => params[:name], :email => params[:email]})
   else
     user = User.new(params[:user])
   end
   if user.save
     render :amf => true
   end
  end

  def destroy
   user = User.find(params[:id])
   user.destroy
   render :amf => true
  end
end

So in this example the destroy method works without having to mix in the is_amf variable. The create and update method has to mix in the is_amf variable because we’re not passing value objects back and forth.

Here is the corresponding AS3 to call these methods correctly.

AS3

function createUser():void
{
  myservice.create([{name:'asdfasdf',email:'aaron'}], onResult,onFault);
}

function updateUser(user:Object):void
{
   //user should be  => {id:1, name:'Aaron', email:'aaron@something.com'}
   myservice.update([user],onResult,onFault);
}

function destroyUser(id:Number):void
{
  myservice.destroy([{id:id}],onResult,onFault);
}

So what do we do to update the create and update methods so they don’t have to use is_amf? Value objects or _explicitType. These are two options to help you map everything the way you want. Here’s how they both work.

Value objects are simple. They boil down to a generic object with one extra piece of information – the class type. In our case. A ‘User’ class. So when you instantiate a value object, and send it over to RubyAMF, all your properties come over in a generic object, but it also sends the class type. Pretty simple. On the RubyAMF side your class type is caught and a Value Object of the same type is instantiated in Ruby / Rails. So if your value object is a User class, it is in turned mapped to params[:user].

So do we absolutely need value objects to get the params[:user] hash to be the correct object? No. RubyAMF uses a special property to handle value objects on the server side. _explicitType. If you send a generic object with the _explicitType property, it will be turned into a corresponding value object for you. It just so happens that the _explicitType is used to map a value object class to params[:classtype]. So we can use this to map our generic object to the params[:user].

Let’s look at how we can update methods so we don’t need to use is_amf.

Rails:

def create
  user = User.new(params[:user])
  if user.save
    render :amf => user.as_single!
  end
end

def update
  user = User.find(params[:id])
  if user.update_attributes(params[:user])
    render :amf => true
  end
end

AS3

function createUser():void
{
  myservice.create([{_explicitType:'user', name:'Aaron', email:'aaron@something.com'}],onResult,onFault);
}
function updateUser(user):void
{
  //uyser should be => {id:1, _explicitType:'user', name:"Aaron", email:"myemail"}
  myservice.update([user],onResult,onFault)
}

So by specifying the _explicitType property, it’s going to put an active record update_hash in params[:user]. Pretty cool. Now I’m not suggesting you use _explicitType at all times as it’s kind of a hack. You should use value objects instead. But hey, you’ll probably benefit from knowing more about RubyAMF.

Please let me know if there are any questions or suggestions for making it better.