- you can write a RhoSync app that either it's completely local or does all of its connections to the Internet either through JavaScript because you can put JavaScript in your HTML templates or through sockets in Ruby. However we think it's generally not the best way, we think the best mobile experience is you sync the data from wherever your backend is we have the information down to the device and then you have that information whether you are online or offline. To make this easier to do we have the RhoSync client embedded in Rhodes and we have a RhoSync server and that RhoSync server turns out like a Rails app just like any other Rails app.

But we also have installed programs that you say "I want to install RhoSync" and we install everything we install the Ruby, the Ruby on Rails, the database, MySql whatever you need to run and so RhoSync is your server and all that RhoSync needs in order to keep data from a backend current with what you have on your device is using what we would call a source adaptor. A source adaptor has six methods: login, query, create, update, delete and logout. You write those six methods in Ruby I assume a lot of people watching this are Ruby developers, so you can imagine that compared to the old way that source adaptors were written for other sync servers if you write it in Ruby you can do a lot in very little.

These source adaptors tend to be like a page or less of code. We ship with a number of source adaptors as examples for like Sugar CRM or Siebel and other enterprise apps. And actually you can get a lot value by just writing a one method 'query'. You write a handful of lines of code that might call your REST backend, in our online tutorial we call it a Rails based REST backend actually you don't know that it's a Rails based REST backend but you call a REST interface and it's like four lines of code, to call out grab the stuff and then you are actually calling the REST interface calling back JSON which gets parsed into a hash of hashes and then as long as you have a hash of hashes then it gets automatically pulled into this server cache in effect and then it's the job of that server and the RhoSync client that is on your device to keep that all up to date.

You as a developer in your Rhodes app you don't know anything about how this thing happens all that you do in your Rhodes app is you assume that the data is current and so you are writing basic ORM code just like you would in Rails with ActiveRecord where you are referring to the objects and their attributes. The original purpose of RhoSync was to partially do sync data but also to give the user that experience that their data was always current and available to them. The side benefit as turned out is that it's created a really great easy programming model. Because now when you write Rhodes apps your data is just there.

You refer to objects and you generally shouldn't have to be doing any network programming, no Net::HTTP calls or pulling data over the wire in XML, your Rhodes app can just assume that the data is always there.