Archive for the ‘APIs’ Category

File Under: APIs, JavaScript, Web Basics

RSS in JSON, for Real?

Photo: Kevin Conboy/Flickr

A short while ago Twitter said they were going to move to JSON over XML, without much explanation other than they like JSON and not XML so much these days, etc. I’m a big believer that everyone has the right to support whatever they want when they want for whatever reason, whether they say the truth or not. Because of that belief, I take with a grain of salt every bit of support for every format and protocol. I assume that just because someone supports it today doesn’t tell you for sure that they will support it tomorrow. Though the penalty is usually pretty high for removing support for interfaces people depend on. They tend to remember it next time you ask for their trust. All that is fair game too.

So anyway, this got me thinking again about the possibility that JSON might take over from XML. What then? Should we give up all the interop we get from RSS just because it uses XML and not JSON? And it’s because of all that interop that that day will never come. A transition may happen over a long period of time, and before it’s complete there will be something after JSON. Because smart people see that, they tend to be conservative about switching just for the sake of switching. It’s why the web, which is entirely an XML application, will keep XML support everywhere for the forseeable future.

In other words, I’d bet with virtual 100 percent certainty that it’s safe to keep producing XML-based RSS feeds.

But people like JSON, there’s no denying that. And a JSONified RSS can totally co-exist with the original XML. So let’s have RSS in JSON? That’s a question that seems worth asking about, at this time.

Turns out it is a very straightforward thing to do. I of course have an RSS feed for Scripting News, the blog you’re reading right now. I wrote a script that maintains JSON and JSONP versions of the same content, automatically. When the RSS is built so are the JSON formats. and

I learned a long time ago to embrace change. It’s why there is a RSS today that is derived from the RSS that Netscape shipped in 1999 and has features of my scriptingNews format shipped in 1997. If the world wants to go to JSON, help it get there in a way that benefits from all we learned in the evolution of RSS from 1997 through 2002. It’s stood up pretty well over the years. And there’s wide support for it, and lots of understanding of how it works. If there is to be a JSON-based syndication standard, we can cut years off the development process by simply accommodating it.

So I put together an invitation to discuss this.

If you find this interesting, give it some thought, and if you have something to say, write a blog post of your own, or write a comment on that page. Obviously there’s no moderation for what goes on your blog, but there will be moderation of the comments. Be aware of that. One feature of the past are personal attacks which are totally pointless and subtract from the discourse, and we should not carry that practice forward. That’s why the moderation. :-)

Otherwise, I totally look forward to hearing what people think.


This post first appeared on Scripting News.

Dave Winer, a former researcher at NYU and Harvard, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.
File Under: APIs, Web Services

Twitter Tells Tumblr: No Friends for You

We hope you weren’t planning to find your Twitter friends outside of Twitter because pretty soon it will likely be impossible to do so.

Twitter has slowly but surely been cutting out major third-party sites, preventing then from offering a “Find Twitter Friends” search feature.

The latest third-party site to lose access to your Twitter contacts is, as Buzzfeed’s Matt Buchanan first noted, hosted blogging service Tumblr. Previously Twitter has cut off LinkedIn and, more recently, photo-sharing site Instagram.

Tumblr still offers a way to find your friends on the service by searching either Gmail contacts or Facebook friends.

Earlier this month Twitter put third-party application developers on notice, saying that the social network arguably built on the backs of third-party developers no longer needs them. Twitter has also been cutting off third-party social networks like Tumblr, Instagram and LinkedIn.

Twitter’s API rules aren’t entirely clear, but the company’s overall position seems to be that developers — including big third-party sites like Tumblr — should be putting their content into Twitter, but not taking anything back out.

That stance, along with the user limits on third-party client software, has soured many developers on Twitter. Thus far though there doesn’t seem to be a mass exodus of angry developers abandoning Twitter. That may simply be because, at the moment, there’s nowhere else to go, though, as always, the open web offers a solution.

File Under: APIs, Social, Web Basics

One Foot on the Platform…

There’s an old and wonderful Little Feat song.

Lowell George’s girlfriend can’t make up her mind. How he describes it is what’s so cool. “She’s got one foot on the platform, the other on the train.”

And that’s the best strategy, right now, for a reporter or blogger using Twitter.

You can’t get off the platform, that’s where everyone is. But you need a Plan B, just in case you have to get off the platform. That’s the train.

You need a tool that allows you to publish to Twitter, and at the same time publish to an open system that can be connected to other open systems. So users can create their own Twitter, the same way they use Twitter to follow many sources, without having to go through Twitter.

Twitter is the platform. The feed is the train.

It might sound complicated, but it’s not.

If Twitter were to cancel my account, I would keep posting, and people who followed me on the train (following the analogy) would continue to get my updates. The people on the platform, however — would not.

It’s how we develop strength, and the power to choose, without leaving Twitter.

If Twitter Corp plans on being nice to us, then they should not have a problem with this approach. Their API permits it. It’s consistent with Dick Costolo’s edict that we should put stuff into Twitter, but not take stuff out of it.

It’s a way to preserve journalistic integrity even if Twitter hasn’t yet figured out if it’s in the business of providing a platform for journalism.

This post first appeared on Scripting News.

Dave Winer, a former researcher at NYU and Harvard, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.
File Under: APIs, HTML5

Chrome 21 Adds New Drag-and-Drop Tricks

HTML5 offers developers a File API with drag-and-drop support to make web apps behave a bit more like desktop apps. Provided you’ve got a modern web browser and are using a web app that supports it (Gmail and Flickr are among the hundreds that do), uploading files works just like moving files on the desktop — drag and drop them where you want them.

The key word there is files, though. Drag and drop a folder of files and you’re out of luck. Currently browsers just ignore folders dropped into them. Chrome, however, recently added folder support to its bag of drag-and-drop tricks. You’ll need to be using Chrome 21 or better (currently in the dev channel).

If you’d like to see how the new folder parsing works, HTML5Rocks has a quick little tutorial on how you can add support for folders to your web app.

The JavaScript required to support folders consists of an extra loop to tunnel through folders and get to “Entry” objects. That’s a slightly different syntax than what you might have seen if you’ve read tutorials on the File API in the past — using “Entry” instead of “File”. There are two new properties as well — .isFile and .isDirectory.

As always with cutting edge tools, we don’t suggest using this one in the wild just yet. You’ll need Chrome 21 or better for it to work and it’s not yet an official standard, but you can learn more over at the WHATWG wiki.

File Under: APIs, Web Services

It’s Time to Build a Twitter-Free Twitter

Image: Twitter.

Twitter dropped a bombshell on third-party application developers last Friday — the social network built on the backs of third-party developers and clever, innovative clients has decided it no longer needs them.

Twitter’s blog post is short on specific details, but the gist of it is that Twitter is tightening up its API access for third-party developers. The company has long viewed third-party apps as unnecessary and previously warned developers not to “build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” But thus far it hasn’t enforced that guideline. Now it seems it will.

In a post on the Twitter developer blog titled Delivering a consistent Twitter experience, Michael Sippey, Twitter’s director of product, seems to say that the company wants its official clients — and only its clients — to be the way people use Twitter. Instead of building clients that pull out of Twitter, the company wants developers to “build into Twitter.” In other words, kiss your Tweetbot, Twicca or Hibari goodbye and get ready for some embedded widgets instead of good ol’ tweets.

Much digital ink was spilled over the weekend denouncing Twitter’s policy change or lamenting the potential loss of alternative Twitter clients. Of course Twitter is in charge of Twitter and when you use its service — or build apps on its API — you must suffer its whims.

But Twitter’s decision to start enforcing its API restrictions “more thoroughly” could end up a great thing if it inspires developers to take the essence of what makes Twitter great — succinct, timely messages to and from your friends — and free it from Twitter the company.

An independent and decentralized equivalent to Twitter is certainly not a new idea. The basic building blocks you’d need to build such a system have been with us for many years — a combination RSS, OPML and perhaps PubSubHubbub would cover of most of it — but until now there hasn’t been widespread client developer support for such a system. After all, why go to all the trouble of building a decentralized network on top of open web standards when using the Twitter API is so much easier?

Twitter’s third-party developers now have the answer to that question — because you can’t be locked out of the open web.

Developer Brent Simmons, perhaps best known for creating the Mac-based RSS reading app NetNewsWire, has a basic outline of how Twitter app developers could band together and make something that not only sidesteps Twitter’s coming API restrictions, but the service itself.

“The interesting (to geeks like us) part,” writes Simmons on his blog, is “what system that works like Twitter could exist without a company behind it?”

Simmons then proceeds to break Twitter down to its essentials: “under the hood, following somebody is really just subscribing to a feed of their statuses. Posting is really just updating a feed of your own statuses. So you standardize on a feed format. RSS would work great, of course, and there’s a ton of RSS reading and writing code out there already.”

Instead of Twitter clients, what you’d really be building is a real-time RSS client. That’s not a far-fetched idea. Dave Winer, the forefather of blogging and creator of RSS, has been building one for years. (He’s also been telling everyone to build a distributed Twitter-like publishing system for years.)

Simmons doesn’t address it directly, but it’s worth noting that building such a system doesn’t preclude using Twitter. It’s not either/or, it can be both. In this scenario you’d write a post in a client like Tweetbot and Tweetbot could automatically send it Twitter and to your own feed. Start with both and then a migration away from Twitter would be smoother. Those that want to dump Twitter immediately could do so, but still keep posting to anyone with a client that supports the open structure. Then, if Twitter really does cut out third-party apps completely, the infrastructure necessary to support an open alternative is already up and running.

Simmons has more details for developers on his blog and in a follow-up post that delves more into the logistical complexities, but the basic message to developers is simple: Twitter’s changes means you need to find a better network for your clients to use.

The better network is the one that’s always been there — the web. The advantage for app developers feeling threatened by Twitter’s API changes is obvious. As Simmons writes, “there’s a practical reason to use the open web: your app can’t be shut down.”

The question is, if there were an open alternative would disgruntled Twitter users embrace it? The main argument against any alternative is the so-called network effect: Everyone I know is on Twitter; why would I go somewhere else? But not too long ago no one used Twitter and everyone used Myspace. Everyone used Friendster. Everyone use AOL. People change; networks move. A distributed version of Twitter sans Twitter might well be the web to Twitter’s AOL, but there’s one certainty: We’ll never know until we build it.