This is my last post to the Kaboomerang blog. The content isn’t going anywhere but I have done a bit of digital housekeeping.

Actiontastic now has its own site and blog at http://actiontastic.com and http://blog.actiontastic.com, respectively.

The new root of my personal identity online is at http://joncrosby.me with a corresponding blog at http://blog.joncrosby.me.

A sincere thank you to all who have read, subscribed, and commented on this blog. I hope to see you on the new sites.

I don’t know about you, but I sure miss seeing new versions of Actiontastic showing up on this blog every few weeks. If I had to guess, I would even say frequent releases were more exciting than my occasional dives into CloudKit and the vision for cross-platform synchronized data using only web technologies.

This isn’t to say that the work on CloudKit is unimportant but only to say that delivering working software has more immediate benefits to readers of this blog than status updates on a project that probably seems invisible to people who don’t follow me on GitHub. Further, the JavaScript portion of CloudKit is holding up several other exciting projects. So here’s what I’m going to do…

Actionatr Absorbs Open Source Actiontastic

Open source Actiontastic and Actionatr are the same thing, so from now on I will refer to the open source Actiontastic as Actionatr, because that’s exactly what it is. CloudKit is still its foundation. It is still being actively developed and already has some really cool features as a platform.

For example, a one-liner will generate a data model that has routes on it plus a matching JavaScript version that runs in a browser or inside Adobe AIR. (When Mozilla Prism gains HTML5 client database storage, things might change.) Another one-liner will publish an upgrade to all desktop clients and migrate data models to match the server models. This includes the offline SQLite models for AIR. It also has the beginnings of AMQP support so that RabbitMQ can push realtime updates to the browser.

None of this is going away. I have, however, realized that the project has such a large scope that Actiontastic 1.0 shouldn’t have to wait on it.

Actiontastic 1.0

Actiontastic 1.0 will still sync across desktop clients as planned, but it will not have a Windows or Linux version. Those will show up when Actionatr arrives. This will allow me to focus on the data/sync part of CloudKit minus the JavaScript/SSB part of it and execute more quickly. It is sort of a Pragmatic CloudKit that includes web tech on the server and Cocoa on the desktop. “Purist CloudKit” will not use Cocoa.

I promised last week to touch base again today and I’m happy to report that the CloudKit gem is available for the brave amongst you to browse and use. I say this because there are several working pieces that are of value right now while the completed gem will take a few more days before being worthy of an “official” release and a push to RubyForge.

http://github.com/jcrosby/cloudkit/tree/master

Here’s what the code straight out of GitHub can do right now after a “rake local_deploy”:

• Generate a small, fast RESTful web app that supports OpenID and OAuth out of the box using Blake Mizerany’s killer Sinatra DSL (more on this later).
• Generate a GWT UI and REST client skeleton for those of you who dig that sort of thing. (A similar jQuery skeleton generator is in the works.)
• Generate RESTful resources with migrations plus ActiveRecord models that have their RESTful routing and authentication baked in.

Things that are extremely close and may be available by the time you read this:

• A rake task for running the app using Adobe AIR.
• JavaScript/ActiveRecord model synchronization stolen from my GWT on Rails project.

Other items in the works that won’t likely be ready when you read this but will appear rapidly, piece by piece, prior to the gem release:

• Desktop application updates.
• Automatic desktop schema migrations that match the server side counterparts.
• Automatic data/resource synchronization between desktop clients and server side storage.
• Transparent offline/online detection and management using the Application Context (a.k.a. MCP) mentioned in the previous post.

I’ll continue these frequent updates as the pieces roll out.

Given the zero dollar budget and the fact that I don’t know people who do the press conference thing, I’ll just deliver the details here and now.

I was targeting today for the CloudKit release. On Friday evening, I began a code-a-thon of sorts to wrap up the last bits of the platform prior to release. The weekend was spent entirely at the computer, bachelor style, with pizza, coffee, soda, and various other forms of sugar in the shape of rabbits. Each remaining bit was scribbled on a white board with a plan to get to Monday morning with the goods.

Sometime on Saturday, I chose to take a risk and drastically reduce the hosting requirements for CloudKit apps (and give it a massive boost in performance as well). Knowing that this kind of change would be a pain for users after a first release (it included an ORM and web framework switch), the risk/reward ratio seemed about right. This part of the work is now done and I am back on track for wrapping up (again).

So, thanks for sticking with me, for being awesome, and for the encouraging comments and emails. Building free software is its own reward but having enthusiastic users makes it even better.

Sneak Peek

For the curious, CloudKit is coming together as an SDK delivered by way of a ruby gem. The installed gem will allow anyone to generate a small, fast web app that supports OpenID logins and OAuth API authorization right out of the box. Stealing liberally from my GWT on Rails plugin, CloudKit will keep data models in your web app in sync with the models in your distributed, online/offline desktop apps (built with the same HTML, CSS, and JavaScript UI on both sides). The center of it all is a tightly optimized bit of JavaScript known as the Application Context.

This Application Context is kind of like the MCP in Tron, minus the evil part. It knows when it is running in a browser or on the desktop and makes decisions about what to do when the network connection is unavailable. Local SQLite storage is used for both speed and network fault tolerance. Based on launch times, network state, and web service information, the wannabe MCP updates client apps to the latest version, migrates their data models to match the server versions, and synchronizes data that is stale on either side.

There is probably a day or two of work left at this point, to be distributed over spaces between the best full time job ever and my role as the luckiest husband and father ever. Let’s touch base again next Monday, shall we?

A few hours ago, Adobe released a public version of AIR for Linux. This makes it the first cross-platform WebKit runtime that supports local SQLite storage. They are the only player in this space at the moment. Although many lump AIR in with Gears, Flash, and Silverlight, it is operating entirely in its own space and this should not be underestimated.

When CloudKit is released, likely on Monday of next week (quickly followed by Actionatr), it will include support for Adobe AIR but the pieces that are AIR-specific have been isolated into their own surprisingly small implementation classes. The end result may come in at less than 100 lines of code. Because of this, I have been working on a Qt wrapped version of the latest WebKit runtime that supports HTML 5 local SQLite storage without having to use a top level “air” namespace. If you have experience with the Qt toolkit or WebKit builds in general and would be interested in working on this cross-platform wrapper, please leave a message in the comments or send an email to my first name at this domain.