Our comments and trackback policy You Link We Follow, You Comment We Promote

There is an awful lot of hassle involved when it comes to passing out the data that is sent to and fro amongst the users and producers. This is due to the endless scrubble of services lying intermediate between the two, creating the longest possible route between the most direct already present. Gnip comes up with an idea of nipping this tiring procedure by sitting between social networks and various other web services that produce a lot of user generated content and data (for example Flickr, Twitter etc). The  service’s launch was reported by Michael Arrington at TechCrunch.

The aim is simply to shed the immense load that sits upon the APIs and making various services more efficient. This is done utilizing the ping server technique that is in use by numerous various services, primarily the blogs. Technorati and various other blog search engines use this ping technique to keep themselves updated with the latest posts/news etc that is made to the blogs. The benefit of doing so is that they don’t have to continually index or re-index sites for keeping up with the updates. This service was first brought to scene by Dave Winer with the creation of Weblogs.com. The result was a massive improvement in blog search engine’s efficiency.

With Gnip to gather simple information from various networks, all that is required in a username, which is then distributed over to anyone requiring it (when it comes to creating a new account at another network). Such services can then access the API after the concerned user authenticates it before it can access the data. Here the user has an option to either push data to Gnip or let Gnip take out the latest data from the user. The advantage of using Gnip is that all the messages pushed up by the user are directly sent to the consumer instead of making its way through various other applications.

What’s the catch? Simple the next time news breaks up you don’t have to Digg it (for example). Gnip can simply ping the service once, without loading the API with continual round ups every time an update is made. Saving both the time and hassle involved at the countless trips to be made otherwise.

However this means that upon a full scale implementation Gnip would be taking bulk of traffic for every services associated to it. But that is the very issue they aim at solving; and for that they have their notification based system. Its fundamentals sort of work like the proxy assigned to web services. Meaning that the data as has been said, need to be pushed once and this can later be either pushed or pulled by other consumers, depending on what they require.

With the entire world moving on towards standardization of services, Gnip comes eliminating all such bounds with its one for all interface that can very well be the core of the web infrastructure.

The service can definitely outshine and become the core of web, but won’t this have an effect? As in what if the service is to go down, with the bulk of data continually loaded, not in a matter of hours or minutes but in seconds? Won’t that somewhat be more of a bottleneck for the World Wide Web as every other information has to pipe itself through Gnip? Just a concern, I probably have a few doubts with emerging overhauls (it seems it might transform the entire scenario).

Gnip was initially developed by Pivotal Labs.