Joyent

Upcoming Slingshot Roadmap

If you hadn’t heard, I’ll be presenting Slingshot at Railsconf Europe in Berlin this September. For the presentation I would like to have product to show and answers to all the questions posed at the last presentation at Railsconf US – so I’m stepping up Slingshot development between now and mid-September.

I want to periodically lay out roadmaps on the list and the Joyent Open Source wiki so that you can keep tabs on what is happening and when it’s expected to happen, as well as provide feedback and testing throughout the process.

I’ve been putting some thought and dry erase marker into Slingshot architecture the last couple weeks and I wrote the first bit of code today. So here I’m going to lay out the first phase, in addition to what we can expect to have produced at the end of the phase. For the time being, the current svn repository will remain AS IS, and all of my work will be occurring in the new directory. Once things have become more solid, and we have a workable base that is at least as complete as what we have now, I will do some repository housekeeping.

On with the description of phase one. I’ll start out with some definitions so we’re all on the same page:

• Primary application: The Web application running on your production servers – the one normally seen through a Web browser (e.g. Joyent Connector)

• Local application: A locally running version of the primary application – runs on the computer using the Slingshotted app

• GUI: The graphical part of Slingshot an end user directly interacts with

• Proxy: A small proxy server that sits between the GUI and the primary and local applications (described in detail below)

• Connectivity: Describes the ability of the proxy to connect to the primary application (i.e. are we “online” or “offline”)

This first phase deals with the development of the proxy component. This component is fairly simple, and is very close to user interaction so it seems like a good place to start. I’ll break its development down into three steps.

Step 1. Create the proxy and make it aware of connectivity. The proxy will know when it is online and offline, the user will not need to manually set this. Provide an API for the GUI to get the connectivity status. This step is about 95% complete at this writing.

Step 2. Give the proxy the ability to start and stop the local application. Many people have voiced concern over the heavy memory footprint of a Rails application. It is true that some applications can grow pretty heavy. This is generally not a problem on production servers, so we don’t give it much thought, however, on the desktop the memory usage of an application becomes much more important, even if it’s only 50MB. So, when Slingshot is in online mode, we’re going to shut down the local application. When Slingshot detects it’s offline, we’ll start the application up. In short, there’s no reason for the local application to run unless we’re directly interacting with it.

Step 3. Give the proxy the ability to fire synchronization events. There are a handful of points where up and down synchs should be fired off. Most of these will be automatic, but the user may want to trigger a sync as well. So at this point we’ll build a mock synchronizer that the proxy can fire events on as if it were really syncing.

After this phase we’ll have a system that can interact with the primary application when online and interact with the local application when offline. This will be seamless to the end user, only the two data stores will be separate. That’s the next phase.

While we’re adding the feature of automatic connection detection, it may seem like we’re taking a step back from what’s currently available in Slingshot. In a way we are, but it’s a necessary step back so that we can take larger steps forward sooner. We’re not discarding the current Slingshot, but we are making some overall architectural changes, and sometimes it’s better to start a new frame from scratch and then integrate existing pieces than to try to mold the existing thing as a whole.

Once this phase is complete, I will move into the data synchronization portion – the main guts – the “hard” stuff. I’ve got a number of cool things sketched out for this, which I’ll detail in my next installment. Also expect a similar post regarding the GUI itself – I have plans to make the GUIs lean and easy to create (so this means PPC and Linux support, etc.).

Until then, please follow development using the Open Source wiki feeds, try things out, give feedback, voice concerns, ask questions, and all that good stuff.

Joyent To Offer Open Source Version of Slingshot

When Slingshot ships, Joyent will use a dual license model similar to Trolltech, MySQL, and Sleepycat.

Open Source and/or Free

Slingshot will be open-sourced under the GPL and available to anyone with a publicly available service that is free (advertising is “ok”) running on the Rails platform. An example of this type of application is Twitter. You will be able to download the source-code of Slingshot, dig your fingers in, and work with it in any way you see fit.

We are planning a number of initiatives in order to build a vibrant community around Slingshot and are currently working to get a number of open source Rails applications working on Slingshot. We have Radiant working, and we will release this as part of the SDK when we ship Slingshot to the world.

Commercial Use

If you plan to use Slingshot for commercial purposes, we will have two types of licenses. One license type will be for commercial applications that are publicly available. An example of this type of application is Joyent Connector. The other license type will be for commercial applications that are not publicly available (either it is behind the firewall or customer cannot sign up for accounts).

Having commercial use licenses allows people to contribute to the continued development of Slingshot as we plan to reinvest a significant amount of this license revenue into further development of Slingshot and support for the Slingshot open source community.

If your commercial application is powered by a Joyent Accelerator, you get a commercial use license for Slingshot for free. No kidding.

Apollo Model?

When we announced Slingshot, Andrew Shebanow at Adobe posted about Apollo, Competition, and Openness.

Next is SlingShot from Joyent and Magnetk. I love Ruby on Rails, so this product is very interesting to me. They basically have taken the all-in-one desktop server approach of Locomotive and turned it into an application runtime. Its a great idea, and one that opens up a lot more power to the local application than Apollo. Downsides are a lot of potential security issues (no sandbox?), the fact that the entire source of your application is distributed to the world whether you like it or not, and the fact that it is limited to Ruby on Rails applications. More disturbing, though, is that it sounds like Joyent will be charging a royalty for distributing applications based on their runtime unless you are a customer for their hosting service. Maybe they just plan on charging a flat fee for the SDK. Either way, this is much less open than the Apollo model where the SDK and runtime are both free of charge.

We are charging a license fee to people using Slingshot for commercial purposes. I believe Adobe does this for content producing tools, too. Joyent would like to invite Adobe to open source Apollo and the ecosystem around it (Flex, Flash). Don’t just make it free, free it.

And by way of response. Sandbox? What’s the sandbox Adobe Photoshop runs in? Entire source? More on that, later. Limited to Rails? Yes. Focus.