We need a little middleware

First, I'm happy to report I will be speaking at the Evernote conference in San Francisco on September 26. The topic will be the revival of the RSS market. Other panelists include people from Feedly and Pocket, two excellent companies, and moderator Rafe Needleman from Evernote. Should be very interesting. I'm glad that Evernote is taking an interest in this area.

Wish list item

One thing I'd love to have working by the 26th is a way to move outlines from Fargo to Evernote. I see a combination of Evernote on mobile devices and Fargo on desktops and laptops could create a really fantastic notetaking system, one that I'd very much like to try.

I wrote the rest of this quickly because I wanted to sketch out the problem. We need to get something general in place fairly quickly.

Today, most services need a proxy in the cloud

Connecting a static JS app running on the desktop to a server like evernote.com, requires an intermediate "proxy" application, that makes up for the limits of what apps running in the browser can do.

There's not a whole lot to these apps, I think they over-complicate what could be a very simple environment, add a point of centralization, and failure. The proxies cost money to operate. Money that's basically wasted.

As with Evernote, we've had to build gateways to connect Fargo to WordPress and Twitter. The user has a bit of structured text, encrypted user credentials, usually created by OAuth, and wants to flow the outline text through your service.

In the case of Twitter (as-yet unreleased functionality) the outline becomes a sequence of tweets, or something like that. Haven't figured this out yet (that's why it's not released).

In the case of WordPress, the outline becomes a blog post. This was the first connector we shipped way back in April. The blogging connection is a no-brainer because I'm myself a blogger and pretty much fully understand the connection.

Dropbox is different

The connection with Dropbox does not require an intermediary server. I think this is because they figured what we would need to work with their service without having to operate a server in the middle. The example they set can and imho should be followed by all web service vendors.

Sketch of how it works

1. Code is running in JavaScript on the user's machine.

2. The user wants to send some text to your service.

3. I offer a link for the user to click on that creates an authorization token of some kind, which I can then ask you for in a few seconds. A simplified OAuth dance. (Don't make a callback, that requires me to reinitialize my whole app, a time-consuming process for the user, and unnecessary. We can poll in the background.)

4. I'll store the token in localStorage on the user's machine.

5. A command will appear in a menu in Fargo that says Send to X, where X is the name of your service. When the user chooses the command, I pack up the bar cursor headline and shoot it up to you.

6. What you do with it depends on what your service does.

7. If I'm going to be able to call you, you either have to have CORS set to allow this, or provide a JSONP interface.

Let's bootstrap an ecosystem

I really want a strong app ecosystem to develop here. People are just waking up to how powerful this place can be.

Amazon opened a store recently for this kind of app (filling out their form is one of the things on my to-do list). Mozilla of course is very active in HTML 5 apps.

Think of it as the unconstrained ungatekept alternative to the iOS and Android worlds.

This is where I want to work. And I want lots of other apps to be here, because until there is we haven't got an ecosystem.

Posted: Thu, 05 Sep 2013 17:27:33 GMT