Released RubyAMF 1.6.5

Hello to all,

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

RubyAMF change admins

Hi there! I’m victorcoder, the new admin for this blog and the new project maintainer for the google code project. As some of you may know, A. Smith the creator and the main maintainer for this project wants to move on from RubyAMF to other cool projects.

My main objective is keep on his work and the work of others in the several tasks that a great project like this, deserves.

I’m really excited about this, because, as a RubyAMF user, I hope we can improve it to make it more popular and feature ritch.

So if you have any questions about this or about the project, you can leave a comment here on send a message to the google group http://groups.google.com/group/rubyamf and we will try to answer your doubts.

Long life to Ruby/AMF/RubyAMF/Flash/Flex/Python/etc/etc/etc! :)

Flex on Rails Book with RubyAMF!

Congratulations to Tony Hillerson and Daniel Wanja for finishing this book. I just received my copy, and have been skimming through it, it’s great! I’m particularly excited about seeing some RubyAMF action. It’s great to see a community around it. Congrats again Tony and Daniel!

-Aaron

Maintenance Release: 1.6.1

Hello all,
There was at least one bug running RubyAMF with Rails 2.1, and I fixed
that today, and all my reference apps (which are what passes for
tests) work, so I’m tagging that sucka as 1.6.1.
You can get that like:
script/plugin install http://rubyamf.googlecode.com/svn/tags/1.6.1/rubyamf


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)

RailsConf next week!

Hey all, this is Tony. I’m going to RailsConf next week. Daniel Wanja (of onrails.org) and I
will be giving a hands on tutorial on Thursday about Powering AIR
Applications with Rails
. We have a ton of material, and if time
allows I’ll talk a bit about 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.

Guttershark Blog, Remoting Framework (SSR) Updates.

Couple things. I thought I’d make sure I don’t pollute the RubyAMF blog with Guttershark stuff. So I’ve got a blog setup for Guttershark now.

I’m also migrating SSR into Guttershark, this is where SSR will be available from now on, and lives in net.guttershark.remoting. I’ve also just added a new RemotingManager class that simplifies working with RemotingConnections / RemotingService classes. As well as integration into Guttershark so that initializing a RemotingManager is as simple as providing a flashVar specifying what endpoints to initialize. There’s a good example in the examples/shells/remoting folder in the SVN repository.

RubyAMF 1.6 released

I’ve been sitting on the code in branches/development for a while now
and I thought it was time to get it into trunk. I went a little crazy
though, and also tagged it as 1.6 and pointed the current tag to 1.6.
There are still some outstanding issues, but I’m running this code in
a stable environment and I wanted to get everyone on the same page.
Here’s the new order of things:
http://rubyamf.googlecode.com/svn/trunk
This is “edge”. There may be unstable code in here, but not by design.
It should be pretty solid for trying out new features or important bug
fixes.
http://rubyamf.googlecode.com/svn/branches/development
This is where experimental features or patches can go.
http://rubyamf.googlecode.com/svn/tags/current
This should be the stablest release available.
http://rubyamf.googlecode.com/svn/tags/1.6
This is the current stable release as of 19 May, 2008
History:
SVN r1275: branches/development goes into trunk
SVN 1276 – 1.6 tagged
SVN 1277 – “current” tag now points to 1.6
Current used to point to tags/release_1.3.3_rev865

Cross-posted from http://tinyurl.com/55b9ax

Guttershark Actionscript 3 Library

I’ve been working quite a bit recently to get this Flash Actionscript 3 library ready. Check out the first beta.

FlexibleRails, Refactoring to RubyAMF

A friend sent me this link a couple weeks back to a short spotlight on Flexible Rails. Check it out

Updating NCManager order of Connection Attempts

I’ve been working a lot lately with Akamai for streaming content. Minus many problems I’ve encountered, and having to write an AS3 AkamaiNCManager class. It’s pretty straight forward.

For a quick background on the what I’m going to show you – checkout the FLVPlayback documentation and look at the ncMgr property. Then read about the INCManager and NCManager. If you read the source code of the NCManager class, it’s pretty straightforward, and you can see that attempts to connect to your streaming application are made numerous times, first to port 1935, then to port 443, then to port 80 over RTMPT (http tunneling), then to port 443, over RTMPS.

That’s quite a few connection attempts to go through, which can cause delays in streams playing. Generally it’s not really a big deal. But in this case – a pretty serious application, I don’t want my apps attempting all of those, or just in that order.

Preferably I’d rather have it first check RTMPT over port 80, because port 80 is always open. Then check port 1935, then 443. It was pretty straight forward after diving into it a bit. I thought I’d share how to re-order the way that the NetConnection’s are attempted in the default NCManager class.

First thing, we need to update the AS3 source NCManager class. Find that source file, and open it up. There is a variable declared like so:


//ORIGINAL:
flvplayback_internal static const RTMP_CONN:Array = [
{ protocol: "rtmp:/", port:"1935" }
,{ protocol: "rtmp:/", port:"443" }
,{ protocol: "rtmpt:/", port:"80" }
,{ protocol: "rtmps:/", port:"443" }
];

//UPDATED:
flvplayback_internal static var RTMP_CONN:Array = [
{ protocol: "rtmp:/", port:"1935" }
,{ protocol: "rtmp:/", port:"443" }
,{ protocol: "rtmpt:/", port:"80" }
,{ protocol: "rtmps:/", port:"443" }
];

All I did here is update it so that it’s not constant, it’s now a var. Note that instead of changing the value of the variable in your class, just change it from const to var. So that in other flash applications, you don’t inherit something in the AS3 codebase you forgot about.

So now to update the variable:

package
{

  use namespace flvplayback_internal;

  public class MySomething
  {
     public function MySomething()
     {
         //change the values.
         NCManager.flvplayback_internal::RTMP_CONN = [
           {protocol: "rtmpt:/", port:"80" },
           {protocol: "rtmp:/", port:"1935"},
           {protocol: "rtmp:/", port:"443"}
         ]
     }
  }
}

Now you can successfully change the order of connection attempts.

Next entries »