contact

mozconcept – file management in online applications

More and more web 2.0 applications reach a level of sophistication usually only found in native desktop apps. One of the biggest topics right now is cloud computing and cloud storage. So I got my docs in google docs and I got my pictures in flickr and so on. Many apps by now already offer the possibility to import files from your local computer and some even are capable of taking stuff from other 2.0 web apps. The problem with this development is that each web app offers an API to make use of the data stored with the service. Now that would mean that every web app that wants to allow the user to user data from other web apps would have to implement all the APIs of each of those web apps. It is obvious that this will lead to chaos, poor connectivity and poor performance.

each line represents a API connection between a web service

each line represents a API connection between a web service

A possible solution:

The next generation browser becomes a hub for all this data APIs. The APIs are implemented within the browser and the browser can then provide the data to web apps as if they were either stored locally or via a unified API. Lets take the simple example of pictures. I have a picasaweb account with google and a flickr account. boot use the same type of data – Image Data – but they are not compatible. both flickr und picasa offer the ability to upload local files. If the browser knows this as well he could then take the picture from my picasa account using the given API and then present it to the flickr account as if it was a local file. This is the most simple implementation of this idea.

The dream would be that all Web apps offer an API that fulfills predefined standards for different types of data. If I then have a webapp like google docs or this wordpress blog and I am asked to upload a picture I do not only get to browse my local pictures but also all the pictures from all of my webservices like google and flickr.

each webservice my use their own API for sending data but will recieve data from the browser if it were local

each webservice may use their own API for sending data but will receive data from the browser if it were local

advantages of this concept:

  • so all the APIs only need to be implemented once in the browser and not by every webserice
  • future APIs can be built directly to this framework which will increase connectivity even more
  • the cloud becomes real as it really does not matter any more where the data is stored

Tags: , , , , , , , ,

This entry was posted on Monday, August 11th, 2008 at 11:02 and is filed under Ideas. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  1. MMcCubbing August 12, 2008 at 09:30

    Not a bad idea, but most likely very difficult to implement. What about if each API was like an add-on or plug-in for the browser. Intially you start of with the major ones and as you browse sites if you come across a site that uses a different API you download the compatable attachment for your browser and *presto* it can start sharing files and information.

    Obviously this would mean that either the browser developer would have to create each of the attachments themselves, or a standard would have to be agreed upon so that the sites’ developers can make it available to their customers.