Office 2.0 Separation of Duty
Friday, February 24th 2006 | Ismael Ghalimi
It seems that every week that passes by brings the release of a new Office 2.0 alternative to Microsoft Excel. The latest in date is called Numbler, and is similar to Zoho Sheet or iRows. What I found interesting with it is the disclaimer that appears on the home page:
“This is an early release. Please do not use Numbler for anything important or mission critical. Numbler should not be used to store confidental information. We are working on a number of features that will better enable you to safeguard your data.”
This reminded me of a concept that I had been thinking about for quite some time now: Office 2.0 Separation of Duty. The idea is pretty simple: while most Office 2.0 services provide a way to both store and edit data, would there be any benefits in separating storage from editing? One that immediately comes to mind is that holding one’s data within a single place would allow this data to be edited through different services, which could be offered by different service providers. Also, I might trust iRows, Numbler or Zoho Sheet to give me a good spreadsheet editor, but I might trust Salesforce.com even more to securely store my data.
If this idea sounds far fetched, you might want to think twice about it, for it has been implemented with success by a Salesforce.com AppExchange application, the much-praised DreamTeam project management service. With this application, as well as most other AppExchange applications, all the data remains stored into Salesforce.com, and the AppExchange partner merely provides an editor for it, usually hosted on its own servers, not Salesforce.com’s.
To me, most Office 2.0 applications should work that way, allowing data to be served by a third-party service and simply providing editing, sharing and publishing capabilities. This obviously brings the issue of public APIs that could be used between data storage and data editing services. For document-centric data, something like WebDAV might do the trick, but for relational data, a web-oriented version of ODBC or JDBC would be required. This gives me a new entry for the Office 2.0 bug tracker.
Many thanks to Emily Chang at eHub for pointing me to Numbler.
Entry filed under: Office 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|











Ever heard of JSR-170 — the Java Content repository API? That is the API I would propose to use, since we are talking about content here, and the services that the API describes are very valuable in that context.
Boris,
I agree that JSR-170 would be an excellent candidate, but we would need an XML-based version of this Java API in order to make it cross-platform.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment