A big thank you to Larry Halff (Ma.gnolia, thmbnl) and Chris Messina for hosting Todd Ditchendorf (Fluid) and me on the Citizen Garden Podcast. If you’re interested in site specific browsers, check it out. CloudKit, the “data everywhere” platform powering Actionatr, is discussed along with Fluid, Prism, AIR and other juicy bits.

In true GTD fashion, I would like to clear the deck of questions or issues that have been inhibiting progress both for updates to this blog and for Actiontastic and Actionatr code. There are things I am ready to begin discussing with you, but don’t want to cloud those discussions with the issues presented here. So, let’s clear the deck so that we can be productive. Together.

The Open Source Announcement

For the most part, the announcement of my open source plan has been well received. A few have been more anxious than others to see the real source code, but I have been reluctant to give out dates. If you’ve been in the industry for a while, you already understand what I’m talking about. Like setting a delivery date for a child, a software delivery date is more like the date when the software can almost be guaranteed not to be delivered. Most of the time, we hope to err on the side of being early, but the safest route is to stay agile, taking things in small increments and getting better with predictions over time as project-specific experience grows. The project-specific experience has been growing for domain-based knowledge such as “What does an ideal GTD system look like?” but has been in great flux regarding the technology being used.

I did, however, make a conscious choice to favor openness at the risk of creating (understandable) “Are we there yet?” sentiments for some. If you have asked about the delivery dates for code, or either piece of software, I count you as a friend of the project and appreciate your enthusiasm. If I had to throw a date out there, I would say October, but the CEO would probably kill me for doing so.

Technology Changes

The number of times Actionatr (and thus Actiontastic…more on that connection in an upcoming post) have been destroyed and recreated would be unbelievable to some. Sometimes progress comes through positive destruction and the code base has definitely benefited from this. From straight Objective-C talking to a Rails app, to a RubyCocoa app, to a Flex-based app, to the current incarnation (again, more in an upcoming post), my ideas for a ubiquitous productivity system have been sliced, diced, and remixed without mercy. I have been on a quest to find the perfect mix of ingredients for cross-platform, online, offline, synchronizing goodness. The latest round of tech is the 1.0 tech and is centered on a core of open technologies that have great promise for now and especially the years ahead.

License Change from GPLv3 to MIT

One of the most complex hurdles was presented by my own choice, that of the GPLv3 license. Targeting this license right away meant that I could not open up the code until everything in it was GPL-compatible. This is no small task for something like Actiontastic, which is built on lots of pieces that have conflicting advertisement clauses. The reason for choosing the GPL was that it seemed to be a nice “pay it forward” way of guaranteeing future openness for any who might wish to contribute code.

In the end though, I chose to move away from the GPL. While the concept itself is indeed beautiful, the pragmatic side of me won the fight with my internal idealist. The software is now using the MIT license which has a different flavor, one that exerts less control and serves more easily as an umbrella over the many components that the software is now using. This means less rewriting from scratch and quicker turnaround for features.

Questions?

Those who still have unanswered questions (not related to feature requests because I’m going to start talking about new features next) are welcome to leave a comment. I will attempt to provide answers where I can. Otherwise, let’s consider the deck cleared and get on with the new feature discussion!

This is my first post from the new residence in Walnut Creek, California. Walnut Creek is located in the East Bay area, near San Francisco. Formerly rooted in St. Louis, Missouri, this move marks the end of a busy period of non-stop work-plus-planning-and-packing, and the beginning of a new era of independent work here in this beautiful state. This move was made possible by encouragement from friends, family and colleagues as well as wonderful clients, both new and old.

Chances are, you are following this blog because of Actiontastic or Actionatr. You have my sincere gratitude for staying tuned in during a period of fewer posts and updates. The move to independent work means that I will be able to blog more frequently and also release an update that we’ve all been waiting for, myself included.

By the way, if any of you will be attending the iPhone Tech Talk in SF tomorrow and would like to meet, please send me an email (my first name at this domain) or a direct message via Twitter.

Last night, talented RedMonk Analyst, Michael Coté posted a write up covering Microsoft’s Astoria project including this tidbit:

“The whole point of Astoria for me is to be a thin, REST-y data-layer on-top of the cloud. The web is The Cloud, of course.”

And, this one:

“Think something like Amazon S3, but with semantics layered on-top.”

Yes! Yes! And, did I mention YES? This idea of a “REST-y data-layer on top of the cloud” is the foundation of Actionatr (although without any Microsoft in the stack). Months of experimentation and research have gone into what is now being solidified in code. Actionatr is a platform that just happens to have a web interface and a Mac interface, but this is really just the beginning.

REST is the new SQL. Sort of.

The Microsoft take on this is to build a tool that plugs into a regular SQL data store, but what I would like to get at are the possible business models that could be built on top of such a thing. In the course of building Actionatr, I was thinking about how we could bake a REST interface into MySQL, but given that authentication and some amount of other configuration would need to take place, more would be needed. I looked at using the newly 1.0 Restlet API to create a fast, configurable, auto-inspecting layer that could be dropped onto any good data model as an easily scalable data layer for RIAs, legacy web apps, desktop apps or a blend of these. Rather than over-engineering my way to permanent vaporware, I decided to just use Rails as a temporary REST-only back end (i.e no HTML interface) and leave the fast, fancy, compiled SQL-to-REST framework for later (as it would not have an immediate benefit for Actiontastic/Actionatr users).

Let’s step back for a moment to trace this evolution. After digging into Fielding’s dissertation that introduced the REST (REpresentational State Transfer) concept and thinking about ways to scale and optimize such an architecture, I came to see the HTTP transport mechanism as one big hash pipe plus four simple operations, mysteriously resembling CRUD and SQL. A hash contains key/value pairs. When a URI is the key and the data is the value (be it an XML representation, JSON, or anything else), the added HTTP request semantics of GET, PUT, POST, and DELETE give us enough information to build naive caching mechanisms at any level of a given architecture.

Getting Clean by Taking Off Your ;close

With this in mind, it is important to note that adding “extra” methods on top of these standards might be harmful if you want to scale. As one concrete example, I added a “;close” method to an existing set of methods for Action resources. Oops. The problem with such a thing is that it destroys the ability to insert these naive caching mechanisms into the middle of an architecture. The caches would have to incorporate new business logic to understand how data inside an Action resource would change after seeing a “;close” request come across the wire. Adding such a thing into what started as a clean hash lookup optimization problem would degrade performance and add complexity for all future model/resource changes.

Thus, solid RESTful design goes beyond mashups and hype. Clean RESTful design allows easier scaling by specifying the complete state for all PUT and POST operations. Subsequent GET operations no longer have to make it back to your core application; they can simply bounce off a lightning fast cache. For that matter, GETs could be partitioned, other operations could be queued and batched, etc., but that is a research area unto itself and beyond the scope of this post.

Domain-Specific RESTful Hosting

So, once you’ve got a clean REST concept going, it is only a small step forward to imagine SaaS (software as a service) models on top of this. What if, oh I don’t know, say Actionatr, pulled all of the standard elements together into a nice API, put it in the cloud, provided hosting for some dirt cheap price, and thus enabled ubiquitous checkboxes for its users regardless of OS or device? What if anyone could use this service, including developers of other productivity apps?

Beyond this, what would other standardized SaaS models look like? How about contact management? Or blogging? Or calendaring? Maybe these models would contain more elements than a good user interface should support (Actiontastic is an example of minimalism in this regard), but that wouldn’t mean that the larger master data models wouldn’t be useful. It might be more like a grab bag than an all-or-nothing approach.

Either way, one could imagine a business model based on domain-specific data hosting. The extra benefit that this would have over a more generic approach like Astoria is that a community could evolve around this domain-specific data in a way similar to the process for building microformats. So, the model could be versioned and improved over time based on collective feedback from many different application providers. In the end, this could be built on top of an Astoria-like framework but it could begin right now, before the abstraction of a framework has to occur. (Anyone want to build such a thing based on database metadata, Restlets and EC2 with me?)

Server Side Rendering is the New Legacy

Taking all of this one step further, consider the so-called “modern” web app. After creating these things for somewhere around a decade, the hackish nature of building interaction models on top of a “page viewing” legacy (bookmarks, back buttons, etc.) is starting to smell kind of funny. It’s not that HTML doesn’t serve its own purpose very well, buy why can’t we just use this HTTP-as-hash-pipe model to build ubiquitous data services and leave the application interfaces to rich clients like the soon-to-be-open-sourced Flex?

Rails creator, David Heinemeier Hansson, has placed an opinion on the 37signals blog that leaves me wondering if it is a late April Fools joke or real commentary. This is not because the post itself is a joke — listening to DHH is usually a good bet — it is mostly because of its timing and proximity to April 1st coupled with April 1st-style comment reactions.

The entire post is worth a read, but there is one bit I would like to highlight, because it matches much of the view online today. To quote:

“The idea of offline web applications is getting an undue amount of attention.”

The key here is the phrase “offline web application” and when considering the implications of that phrase, DHH’s assertion makes sense — who cares? This isn’t to say that bandwidth is ubiquitous, but rather that a so-called offline web application doesn’t make much sense. An adjustment of terms and perspective might prove helpful in this regard.

In my admittedly biased opinion, it shouldn’t be about taking a web application “offline” or taking a desktop application “online” for that matter. Web applications are a user experience compromise. Desktop applications are a user experience compromise. Why would anyone want to bring the compromises of one paradigm into the other?

I think Brent Simmons got it right with NetNewsWire and its online companion and I hope to see, use, and build more of these hybrid applications. It isn’t about taking something online or offline. It’s about not compromising user experience.

Simmons mentioned the difficulty of syncing these two different worlds in his C4 appearance and I agree that it is a hard problem to tackle, but in the end I think it is a win for users. Someday we’ll lose these primitive ideas of apps running on this or that machine, or being online vs. offline, but right now, I think the answer is to put in the extra work, build both, and sync where appropriate…at least for ToDo lists and probably for many other domains.