August 02, 2007 - by jason
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:
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.