Please note, also, that this page is extracted from the running system, so ignore the links at the bottom of the document.

So, I took it to work today and left my MacBook at home. And guess what? With the exception of one critical type of task, there wasn’t a single thing I needed to do that the iPad didn’t handle fine. I scheduled two meetings, answered all my email, previewed two presentations, worked on some content in our Wiki, made a couple of phone calls (Skype), and checked the traffic on the way home.

That involved using only one app that isn’t part of the basic, out-of-the-box iPad, and that was Keynote from the iWork suite. It happily worked with the Exchange server in the office, the MediaWiki install, and even hooked up OK to the projector for briefings.

What it couldn’t do, even with the full set of iWork apps (Pages, Numbers, Keynote) was anything resembling a decent outline. No concept of outlining exists anywhere that I could find, at least not in the sense that MS Word or PowerPoint can perform. And it’s not a function I can do without on a regular bases.

Outlining in a Wiki is possible, but difficult to share (and preview, and reorganize, and restyle, etc.) and requires a live network connection of some sort. But the stock iPad plus iWork apps just can’t. Not in any useful way.

The device is pitched to students and teachers as a great note taking tool. I say BS. It’s not, unless what you are writing is a disorganized pile of text.

I know there are several 3rd party apps for outlining, but they suffer from a distinct lack of integration with iTunes and the iWork online site for file sharing. And I really don’t think this is a feature to be omitted from the iWork apps.

But in the absence of this feature, I’m still going to have to drag my laptop to meetings unless someone has a better idea.

The ability to embed rich media types directly in the fat ping message would open up a lot of new application types. Image feeds, pushed audio (think instant voice mail), and other sorts of mixed media (multipart MIME, HTML with accompanying media, for example) would all be possible if clients knew how to interpret the type of media before trying to render it. Adopting an optional attribute that specified a MIME type and possible encoding format for content-containing entities would be a HUGE addition to this extension without requiring much, if any, additional work by client authors.

An example might look like:

<description type="image/jpeg" encoding="base64">...base64 encoded jpeg spew here...</description>

The PubSubHubBub spec supports embedding non-text content types in fat pings as a side effect of the Atom spec’s “type” attribute on content entities. However, they don’t explicitly support specifying an encoding scheme.

As with Atom, RSS assumes specific types (e.g., text with embedded mark-up) in the absence of any specifier. So the addition of a “type” attribute is purely optional and would provide clients looking for it with rendering hints as well as an ability to avoid trying to display content types they don’t understand. The up-side is that we get the ability to push all sorts of media and not just text. I think this would be an awesome addition going forward and it should be completely backward compatible with any RSS clients that parse properly formed XML.

Adding both content type and encoding format makes the payload of a fat ping essentially identical to the body of a HTTP response in terms of information available to the client. And every modern OS out there has all the tools needed to interpret and render that sort of message. It also provides a small, but critical addition not present in the Atom/PSHB stack with respect to encoding schemes.

So, my modest proposal is to add optional “type” and “encoding” attributes to the <title> and <description> entities as described above.

First of all, I’d settle for splitting the $40,000 prize. I’d enlist 2 other people, one on the other coast and one somewhere in the middle, and offer them $5000 apiece to play along. Each of us would have gotten up this morning and lofted 3 or 4 big red weather balloons of our own around San Francisco, Austin, and the DC area.

Then we’d have enlisted a couple of our high-flow Twitter buddies for another $2500 apiece to toss out the following offer:

The first person who sends me legit coordinates for a particular red DARPA balloon will be guaranteed $2500 of our winnings.

That means we’re out another $25000 for all 10 coordinates (obviously we aren’t paying for our decoys — they aren’t DARPA’s), for a total of $35,000. A few more posts around the net in our spare time, and bam! all 10 coordinates show up and everyone’s a winner.

I’d be surprised if anyone tries all the elements of this strategy, but it’s sure what I’d do. Fake out the competition and incentivize people who might not otherwise stand a chance at the $40,000 (and pocket $5000 for myself).

So, anyone seen any red balloons today? $2500 of my winnings if you have!

I learned a lot about the pros and cons of using Google App Engine while making my Java implementation of a rssCloud server, rssNimbus. It seems like a perfect platform for hosting a thin set of Twitter APIs that can form the basis of a hackable open source effort at giving Twitter a brain.

I’m going to start a SourceForge or Google Code project to host the Java code. As for collaborating on the proxy “language”, I’m open to suggestions. Google Docs? Wave? Mailing list?

Anyone who is interested in participating please drop me an email at “chuck -at- shotton dot com” or post a comment here.

The example he used was wanting to un-follow a particular user for a day, then re-follow them automatically. It’s certainly possible to build this sort of functionality into an existing Twitter client, but I’d like to suggest something easier than herding all of the Twitter client authors in this direction. Specifically, rather than having the scripting support built into a Twitter client, why not just ask Twitter client authors to allow their clients to be pointed at alternate hosts that implement the Twitter APIs besides Twitter’s own servers?

This would allow us to implement Twitter “proxies”, so that even the most basic of Twitter clients could take advantage of all sorts of extra features and functionality that might get wrapped around those APIs. Using Dave’s example, here’s how it might work:

User configures their copy of UberTweet (a fictitious Twitter client) to use APIs at www.spiffyubertweet.com. Now when they use their client, all of the calls will pass through the Twitter proxy at www.spiffyubertweet.com, where all sorts of magic can happen. In the simplest implementation, the proxy just passes all calls to Twitter and all responses back to the calling client  with no mods or changes. The fun comes when the proxy starts paying attention to the content of the tweets.

Suppose that the user wants to un-follow “pottymouth” for 24 hours. Why not send a tweet like:

<unfollow pottymouth for 24 hours>

The proxy would catch that tweet, parse out the syntax inside the <>, and issue the necessary API calls to unfollow pottymouth. Then it would queue up a task for 24 hours later to re-follow pottymouth for the requesting user.

Twitter never sees the tweet. The client author had to make an utterly trivial modification to their client, and the user can suddenly reap the benefits of whatever services the proxy author chooses to insert into the pipeline. Proxies could allow all sorts of external meta data to be associated with a tweet, for example. Or you could envision Twitter proxies that performed all sorts of analysis on tweets and followers and return reports to users. The opportunities are endless and it requires virtually no work on either end of the existing Twitter ecosystem beyond allowing expert users to specify a Twitter API proxy in their Twitter client’s preferences.

There are several client-side scripting engines that support acting as both a client and a server and they are fully capable of implementing the Twitter APIs, even if most are only pass-through calls. The only thing holding this up is finding a popular Twitter client author that is interested in adding this tiny modification to their code. Any takers?

You can find details on installing and running rssNimbus in this blog post. As a note to developers, you should use the Google Eclipse functionality to install your version of rssNimbus on Google App Engine instead of the command line tool as referenced in the blog post.

This source code is being released under the Creative Commons Attributed-Share Alike 3.0 license, which means you can pretty much do what you want with it as long as you give me credit and you make changes available under similar license terms.

1. download a copy of rssNimbus. <http://www.shotton.com/files/rssNimbus.zip>
2. create a Google App Engine account. <http://appengine.google.com/>
3. download  the GAE SDK for Java. <http://code.google.com/appengine/downloads.html> or the current version directly from <http://googleappengine.googlecode.com/files/appengine-java-sdk-1.2.6.zip> (we need the “uploader” tool from this archive in a minute.)

Setting up GAE

The first thing you need to do is configure your GAE account so that you can upload a new application. Go to the GAE start page <http://appengine.google.com/> and click the “Create and Application” button.

Fill in a unique ID for your rssNimbus install (it must be all lower case and globally unique across all possible GAE apps) and give it some meaningful title and hit “Save”. Make note of the unique ID you created.

Installing rssNimbus

Extract the folder from the rssNimbus.zip archive. It will make a folder called “war”, which is the web archive containing all of the parts of rssNimbus that will be uploaded using a tool in the SDK archive you downloaded earlier.

IMPORTANT! You MUST edit one file in this folder in order to provide GAE with the unique ID of your app. Inside the “war” directory is a subdirectory called “WEB-INF”. In that directory is a file called “appengine-web.xml” (war/WEB-INF/appengine-web.xml) that you must edit with a text editor, changing the <application> value from “sampleUniqueID” to the actual value of your app’s unique ID.

The Google page at <http://code.google.com/appengine/docs/java/tools/uploadinganapp.html> describes in detail how to upload a new app. Here are specifics for doing this on Mac OS X or Linux from the command line.

- run the terminal application of your choice (Terminal.app on the Mac) and change your working directory to the directory containing the unarchived GAE SDK for Java and the “war” folder (e.g., cd ~/Downloads/ )

- assuming your “war” folder is also in the same location as the SDK, use the following command to upload your new GAE application:

For Mac OS X:
./appengine-java-sdk-1.2.6/bin/appcfg.sh update war

What Now?

You can now visit your GAE dashboard and confirm that the new application has been installed (current version should be “1″).

You can visit your rssNimbus server’s home page by pointing your browser at <http://yourUniqueID.appspot.com/>, substituting your actual unique ID in the URL.

You can use the forms on the rssNimbus home page to test pings and subscribe requests. There is a basic /admin page that also shows active publishers and subscribers.

You can get MUCH more detail from the GAE dashboard pages for your app, including access logs, database contents, queued tasks, etc.

Setting Expectations

There are a few things to look out for. The first pings and notifies to and from your server will take longer than you might expect as GAE sets up databases and task queues for your application. Subsequent requests will go much faster.

rssNimbus does NOT currently expire subscriptions. It deletes those that fail (in order to limit lengthy, CPU-expensive failed HTTP requests) immediately.

If you have questions or comments, please post them as comments here.

Be forewarned that it still needs to be hooked into GAE’s cron processes so that hourly housekeeping can be performed (i.e., expiring subscriptions, pushing out delayed notifications, etc.)

Also, please note that as of this iteration, no subscriptions are being expired.

You can find a test version of rssNimbus at http://rssnimbus.appspot.com/ with additional instructions on its home page for using it. Please post any comments, issues, bugs, or feedback as comments to this post.

Once the final kinks are out of it and the basic UI is turned on for admin functions, a user-installable version of rssNimbus will be made available as a .zip archive for anyone who wants to take a shot at installing and running their own GAE-based rssCloud server. Hopefully that archive will be available this weekend, depending on feedback and last minute issues.