diego's weblog

there and back again

Monthly Archives: October 2007

opensocial: standards-based apps for all social networks

It’s all over the wire: the NY Times and Techcrunch first, quickly followed by Om and many others have posted about the announcement that we at Ning were going to make with Google and other providers on Thursday of a new set of APIs that will be supported across all services to enable social applications.

One of the things that is really significant about this is that it’s not vaporware. While the announcement doesn’t mean immediate availability, we do have, right now applications running on multiple test environments. What is also significant is that we’re not inventing a new markup language or things of the sort: it’s all standard XML, HTML, and Javascript. This is the key to bringing a high level of portability, which we will have right out of the gate.

For example, we have a great Flixster app that we will show, which runs on both Ning and Orkut, as well as others, unchanged. This is huge.

Let me say that again: as opposed to what some reports are suggesting (Mashable mentions some of these concerns for example), these apps can run unchanged or with fairly minor changes (if you’ve gone “off-road” from the base calls) in most if not all the supported containers. Will they all be able to run unchanged? Probably not, but it’s possible and certainly something that we should all strive for.

At Ning we are committed to supporting as much cross-service behavior as possible.

Given what the APIs are, and that it will be straightforward to add support for them, I expect we’ll see lots of sites getting behind this effort. Marc Canter just said that they will support OpenSocial as well and on a related point I agree with him: we need to make these APIs deeper.

Additionally, we should make an effort to make the APIs cleanly extensible and provide a mechanism to allow the extensions to become part of the standard. I mean, it’s obvious that there will be *some* extensions, and it’s also obvious that some of them will have wide applicability. And when they do, it’s going to be great if everyone that wants to can jump on board.

There’s still lots of details to work out, but this is very exciting. I’ll post more after the formal announcement on Thursday.

PS: for the record, regarding the New York Times headline of people “gang[ing] up” on Facebook, I can say that I’ve never heard anything even remotely approaching that sentiment. I would certainly welcome Facebook’s support for OpenSocial, and I imagine many others would, too. What Facebook has done is great — this is going to be even better!

macfuse

Must-have for Macs: MacFUSE and its useful friend MacFusion.

the ning platform: yes, it is THAT cool :)

Albert Wegner from Union Square Ventures wants a new Platform.

He describes some of the characteristics of this new platform as follows:

A platform that is created from the ground up to enable modern web sites and applications. What would such a platform look like? It would be hosted and (nearly) infinitely scaleable. It would provide object storage that’s as simple as saying “here’s an object, store it” (you get back a handle, ideally, if you want a human readable, search engine optimized one). Later on, retrieval should be something like – “here’s a handle, give me back the object” (with full user level access control baked in). Stored stuff should be easily indexed so that one could say “give me back all the handles for objects that match this pattern” (and to which the user has access). The same should work for media: “Here’s a picture, store it for me with this metadata” and “Find all the pictures for me tagged x.”

Aside from storage there are other useful services the new platform should come with, since essentially every modern web site / application needs them, such user authentication, authorization and access control. Flexible processing of pretty URLs. Easy creation and maintenance of page templates. Ability to send emails and process bounces. Handling of RSS feeds (inbound and outbound). Support for mobile access and possibly even voice capabilities.

Code would run inside the platform (this is what Marc Andreessen calls a Level 3 platform) but it would not be cut off from the outside world. It would have full access to other services that live on the net via web services. So, for instance, there would be no need for the platform to have its own payment service.

Then he goes on to add:

Marc Andreessen lists companies who are working on it now, including his own Ning, Salesforce and Amazon. […] Despite the big guns already working on this, I believe there is still an opportunity for someone new to build the new platform.

(My emphasis)

Yep, he mentions Ning, but obliquely as “working on it” along with others. Ning is not just “working on it,” but we already have it running, and most of this has been running since the beginning — in fact, at the developer’s level, this is what we’re about.

Allow me to explain: let’s go over some of the requirements he mentions in more detail:

  • A platform that is created from the ground up to enable modern web sites and applications.
  • Hosted and (nearly) infinitely scalable.
  • Simple Object storage (not relational), supporting indexing, tagging, searching with user-level access control baked in.
  • Built in rich media support.
  • Flexible processing of pretty URLs (URL Rewriting).
  • User authentication and access control.
  • Messaging support.
  • Syndication support.
  • Everything exposed through webservice APIs.

Every single one of those requirements is currently satisfied by Ning. As I said before, this is not stuff we’ll release next month, or next year, or “at some point”. It’s stuff that’s running right now, and that has in many cases (such as the webservice APIs) been running for the full 2 years of Ning being live.

Thinking that Ning is “only” about providing easy-to-setup social networks is a common misconception with Ning, and we’re working to improve the documentation to make this obvious.

A lot of things on Ning are about the APIs we provide, and for a good reason. As I wrote before, you can think of the Ning platform as a giant API with a built in ability to execute arbitrary code against it, and both the code and the API access will scale transparently with your needs. Every Ning network runs on top of the API — there are no “special backend systems” or priviledged data paths, or anything of the sort. Therefore, the Ning platform is fundamentally different in this sense.

Here are some specifics of how the Ning APIs make this possible — “this” specifically the requirements and functionality that Albert was talking about in his post.

  • Ning provides APIs and default pages and UIs for user authentication and user account management.
  • Ning’s PHP APIs actually just wrap the Ning REST APIs. The REST APIs are front- and back-end symmetric, i.e., every single API is accessible from both the external world (as a webservice) and internally from the Ning execution environment itself. Internal requests are automatically validated for access (given the user’s current login/pwd) and external calls support HTTP Authentication.
  • The Ning Content Store supports, through the REST APIs, arbitrary, dynamic content shapes that don’t require a schema to be predefined (the schema is dynamically defined at runtime). For more on this see The Ning Content Store: A Primer.
  • The store also scales transparently and has implicit fault-tolerance.
  • The Ning backend supports image manipulation after upload, including resizing and rotation, and video transcoding from most current Codecs into Flash.
  • Rich media (including arbitrary attachments) can be stored as attributes within Content objects and then referenced normally, using the built-in search mechanisms, tagging support, etc., along with high-level aggregation functions that, for example, automatically return tag clouds for content you upload.
  • Content is available (given appropriate user credentials for private content) through built-in Atom APIs that can be consumed in any feed reader. Additionally, the social network application provides many built in wrappers for feeds in RSS format.
  • URL Rewriting is built in. (Note — we use this a lot, but our Forums and Blog still lack in this respect, so the permalinks are, let’s admit it, pretty ugly).
  • There are also APIs for searching, Messaging, role management, and large-scale group formation and management.

On top of these base services there’s the Social Network code itself, which you can obtain for your copy of the network (it’s free, after all) and then modify at your heart’s content. This code contains tons of higher-level functions, libraries and APIs that can be leveraged to build higher-level components very easily.

We will improve the documentation and examples in these areas dramatically over the next few weeks and months, but in the meantime, if you have special requests or questions, you can join the Developer Network and post them. Or just ping me. :)

one small REST call for man, one giant API for mankind

Here’s a question I’ve heard a couple of times recently: how committed is Ning to the platform idea?

It’s question that emerges from our need to focus right now, as a company, on building out the social network application on Ning and empowering Network Creators from the top-down, through simple but powerful tools, to customize and evolve their networks.

Given our limited resources, this creates sometimes the external impression that we’re not paying much attention to Ning as a platform, or to the evolution of our APIs, or the support of them, but nothing could be further from the truth.

Without the platform, there is no Social Network application. Allow me to explain.

When you create a network on Ning today, you get to add features, customize its appearance, change profile questions, privacy options, and more, all through a straightforward drag-and-drop user interface.

Hidden in this process is the fact that the network itself, and every feature in it, uses the APIs of the Ning platform to do the job.

“But wait,” I hear you say, “everyone and their pet has an API these days! How is Ning different?”

Here’s the difference: Every single Web API out there, except for Ning’s, is a parallel plug into the backend that runs the service, website, or application in question.

Every other web site out there (that I know of) has a set of separate systems that deal with API requests — it’s how API access to other sites can be slower, or more unpredictable, or be more restricted than access to the site itself (see the image to the right for the Layers in typical websites). Every site has its databases and various server systems that compose the service they provide. Then (in most cases after the service has been launched) an API is added as a way to expose some of the data or services provided by that website/product. I am not aware of any API out there (except for Ning’s, that is :)) that exposes all of the website’s services in API form — perhaps GData‘s comes closest. Most APIs allow you to read data, sometimes a lot of the available data, and a few let you perform several specific write operations–GData again being a good example of this.

So what is it with this exception I keep making for Ning? What’s special about our APIs?

The answer is there when we look at it the other way: it’s not so much that Ning’s APIs are special, but that the Ning Social Network is built entirely using them. Every application on Ning written by Ning is built using the same APIs available to anyone else on the platform (and even for external remote calls).

Anyone could have built the Social Network application on Ning, starting from scratch. There are no special, high-privilege data paths. There are no hidden authentication systems. There are no datastores that are available only to Ning.

Layers within the Ning Platform

 

The Ning platform is one giant API that runs on what we call the core, a collection of hundreds of servers and dozens of server types that power the platform, presenting a homogeneous view of data and services through a variety of HTTP-based REST APIs.

The Ning APIs are built using REST, but PHP applications running on Ning have access to them through a thin layer of PHP code that simplifies their use from within PHP. However, it is possible to use the Ning REST APIs directly from PHP, It’s just a little more cumbersome. In the future, when we add language wrappers, we will use the same APIs as the underlying mechanism to access the Ning services.

So going back to the question: how committed is Ning to the platform? The answer is simple: We are 100% committed to it — if we were to remove features, or change them, or disable them, every network on Ning would be affected.

The reliability, performance, longevity, and availability of the Ning APIs is exactly the same for everyone modifying the Social Network code, or creating new apps from scratch.

The platform is our DNA. Simple, but not easy. :)

2 years of ning!

2 years ago tonight we launched Ning. Back then, every time we told someone “It’s an online Platform for Social Applications” we’d generally get back puzzled stares. Today, it has become more mainstream (although not completely), and a little over a week ago we passed 100,000 networks on the platform. But there’s still more to do. And a lot more coolness down the road. :)

Follow

Get every new post delivered to your Inbox.

Join 383 other followers

%d bloggers like this: