Juggernaut (Server Push) & Air (Apollo). No need for FDS anymore!

June 13th, 2007

For those of you who don’t know, Juggernaut is my plugin that extends Rails to let you use server push (like comet) which allows for all sorts of collaboration - see the Juggernaut site for more information.

Air (basically Flash for the desktop) has a html component and advanced JavaScript integration where you can manipulate Actionscript objects, and call Actionscript functions - all in JavaScript.

Juggernaut already had the ability to integrate with Flex (via the Flex-Ajax Bridge), however I never provided any examples - and I haven’t heard of any people exploring this route. However, I’ve been tinkering around with a Air class that basically lets you pass JavaScript (perhaps generated via RJS) from a socket server to Air, and then have it evaluated with the html component. This gives you access to Air from JavaScript, heck - you could even build the entire Air interface in JS!

Let me show you an example:

# Rails side
def send_alert
    render_with_juggernaut :juggernaut => 'chat_channel', :update => true do |page|
     page << 'window.runtime.mx.controls.Alert.show("Hello from Rails!")'
    end
end
//Air Side
public function init():void {
   juggernaut = new AirJuggernaut('localhost',5000, ['chat_channel']);
   juggernaut.connect();
}

And, sure enough, when the Rails side is executed, an Alert appear on your Air app.

So, after I showed myself it was possible, I set about making a proof of concept chat application. You can download the application and source below. I’ve set up a push server and Rails application, which the Juggernaut chat app will automatically use (this server will come offline after a couple of days).

picture-5.png

Please hold in mind that this opens up quite a security hole in your Air app. Just as you have to authenticate the Air clients from the Rails side, you must also find a way to authenticate the Rails server from the Air client. The JavaScript has full access to your file system, and this technique is vulnerable to man in the middle attacks! So, this is purely proof of concept and, until we have some secure way of authenticating both sides, I wouldn’t use it in production. Adobe do provide a JavaScript sandbox for JS fetched externally, however this technique bypasses it (and I’m now sure how to invoke it manually).

So, this opens up tons of possibilities for applications that need real-time communication, without having to use an expensive product (FDS) or a resource heavy server (red5). Sure, it’s doesn’t provide any sync or real-time video that other solutions offer, but it should appeal to those wanting a very lightweight approach.

AirJuggernaut Actionscript class

AirJuggernaut chat example
AirJuggernaut chat example Actionscript source
AirJuggernaut chat example Rails source

Air (Apollo), Juggernaut | Comments | Trackback Jump to the top of this page

7 comments on “Juggernaut (Server Push) & Air (Apollo). No need for FDS anymore!”

  1. 01

    Hi,
    I’m just curios why do you choose to eval the data received from Rails server in the AIR client context? This opens - as you pointed out - a security hole as data comming from remote content gets to be evaluated in the local context.

    I think that the right approach for this kind of communication would be to just parse the data received and display the chat line(s).

    Best regards,
    Dragos

    Dragos at June 15th, 2007 around 8:56 am
    Jump to the top of this page
  2. 02

    You could, as you suggest, just parse the text. This would be fine for chat - but too much of a limitation if you want to get any more complex. For example, let’s say you want to send status updates, share files and show a list of connected peers.

    However, perhaps a good compromise would be to send json ‘commands’, which could trigger functions in Air. This would be less of a security risk, and yet you’d still have the ability to make the system more complex if needed.

    maccman at June 16th, 2007 around 2:34 am
    Jump to the top of this page
  3. 03

    I think as Alex points out you could use this technique to create your own interface into Apollo to push command metadata through. Essentially creating a MessageBus to Apollo. The possibilities are endless, the security hole is only there if you allow arbitary javascript evaluation.

    Stuart Eccles at June 18th, 2007 around 5:45 pm
    Jump to the top of this page
  4. 04

    […] Alex MacCaw has posted a really nice example of how his Juggernaut plugin for server-side push can be used with Adobe’s AIR (formerly Apollo) runtime to create a simple chat application. […]

    Jump to the top of this page
  5. 05

    To be fair, your title is a bit of an exaggeration. Don’t get me wrong, I’m all in favor of standards-based, open, free, what-have-you solutions, especially where there’s a point need that Adobe can’t address. To that end however, simple push over HTTP Keep-Alive is hardly LiveCycle Data Services.

    On the push front alone, you mention security which is something that LCDS can provide, and integrate with existing security infrastructure (i.e. LDAP). LCDS will actually try to make a connection over binary socket first, which provides blazing fast communication on the order of sub-second messaging (as required by our financial industry customers). If that doesn’t work, LCDS can fail-over to socket tunneling (RTMP). If that still doesn’t work, it can fail-over yet again to HTTP polling (max. 1 poll per second). That alone is far more than just push.

    For what it’s worth, I’ve often asked for Keep-Alive support as yet another fail-over option.

    Beyond push is data management features in LCDS. These features enable the occasionally connected clients (OCC) that Intel dreamed up for the web a number of years ago (think Central). Implicit data delta packets, undo since last commit, data synchronization across clients, integration for conflict resolution and more. It should go without saying that the Hibernate adapter, Spring adapter, and now the SQL Assembler make all that possible in just minutes.

    I haven’t even touched on the proxy features, service endpoint security and abstractions, PDF generation, etc.

    Again, I think what you’ve done is great, and I’ll likely use it in a demo myself - so please don’t take this as argumentative. To be sure though, simple push is a far cry from replacing LCDS.

    Kevin Hoyt at June 18th, 2007 around 11:23 pm
    Jump to the top of this page
  6. 06

    Kevin, LOL, of course - I realize this. It was meant in light hearted terms (and to make people open it in their feed readers ;)

    maccman at June 19th, 2007 around 2:48 am
    Jump to the top of this page
  7. 07

    Heh, that’s exactly the kind of blog post title I would have used when I was 17, if blogs existed back then :) Good stuff…

    By the way, re. your “now all we need is ActiveRecord for Actionscript” comment the other day–I remember thinking something similar when I was reading the docs about Proxy and callProperty, wondering if it could be used to do method_missing style stuff. Of course, I have no idea as to the scale of the task, other than that I have no time to do it :)

    Peter Armstrong at June 20th, 2007 around 3:24 am
    Jump to the top of this page

Leave a Reply

  •  
  •  
  •  

You can keep track of new comments to this post with the comments feed.

19yr old hacking away at Ruby on Rails and Flex

Pages

Meta