Disclosure: Zoho is a sponsor of R/WW.
Late last week, Web Office
provider Zoho and online storage company Omnidrive announced a partnership,
allowing users to edit a Zoho office document and save directly into Omnidrive. Also,
both Omnidrive and Zoho released APIs. The news
has already been covered in-depth elsewhere - e.g.
TechCrunch and Zoli's Blog. As
Zoli Erdos pointed out in his post, the partnership is a useful step forward in seamless
on-and-offline computing.
The other thing of interest is how both companies are working on data standards for web apps and storage. Omnidrive is positioning itself as a central data provider for not just Zoho, but over time for other web applications too. As Omnidrive CEO Nik Cubrilovic told me in an email:
"...right now we let our users read/write files to various web apps through our 'live folders'. For eg. You can create a Flickr live folder which will let you read/write your Flickr files, in the similar way the above partnership with Zoho works. The whole point is to allow users to bring together not only all their desktop data, but also all their data from the various different web applications they use."
Omnidrive plans to develop a standard protocol for web applications to read/write to storage providers such as Omnidrive, and their LiveFolders format will become an open protocol. Omnidrive and Zoho are also working on a set of standards for application-to-storage communications.
I hope we see more of these types of partnerships between web app providers - and more data standards that others can adopt. The big companies have a part to play too, but don't hold your breath for open data standards from Microsoft or Google.
In the end it's all part of the best-of-breed ecosystem for web apps, which gives power back to the user to choose which apps to use for which tasks. That's the ideal web world anyway, but we'll see how it pans out.
Listed below are links to blogs that reference this entry: Zoho and Omnidrive Working On Web App Data Standards.
TrackBack URL for this entry: http://www.readwriteweb.com/cgi-bin/mt/mt-tb.cgi/1905
It's Saturday morning for me, Friday afternoon in Silicon Valley. Before I go off to the horse races this afternoon (because you needed to know that), here's a quick re-cap of the past week on Read/WriteWeb and in the Web... Read More
Comments
Subscribe to comments for this post OR Subscribe to comments for all Read/WriteWeb posts
The reason its important to be able to switch the storage providers is the same reason that it was important to have J2EE API in the enterprise - to gain freedom from the vendor. OmniDrive, Amazon, Google and others should come to the table to make it happen.
Alex
Posted by: Alex Iskold | January 24, 2007 7:09 PMWrong about Google.
If you look into their Google Base Data API, they are very clearly working towards an open data standard.
Posted by: Kyle Brady | January 24, 2007 7:35 PMWhat we need is JCP (JavaCommunityProcess) - like entity for all the new emerging technologies. Then it will be clear and organized. Question is who is going to be "Sun" and get it going?
Alex
Posted by: Alex Iskold | January 24, 2007 7:44 PMwhy the rip on giggle? what did i miss?
mircosoft has a history, here - does giggle?
Posted by: Peter | January 24, 2007 8:11 PMWell I was mainly referencing Google's routing around of microformats in things like Google Base. But maybe I'm off base, so feel free to tell me reasons why it isn't true.
Posted by: Richard MacManus | January 24, 2007 8:24 PMUm...what about WebDAV?
Posted by: chad | January 24, 2007 9:40 PMWebDAV is an awesome technology standard that solves exactly the problem Zoho and Omnidrive are working on... except WebDAV has no financial owner/backer.
This would be an example where best of breed technology is *not* sticking in the marketplace because a) its too techy and b) nobody wants to support it and when you might be able to claim IP.
Remember Windows 2000 'web folders' feature in their Explorer? That was WebDAV. SharePoint actually still supports it too, but in general its quietly slipping under the waves.
Posted by: John Milan | January 24, 2007 10:03 PMWebDAV has a big backer: Microsoft. They even care enough that their implementations of it are slightly non-standard (thats when you know M$ really cares ;).
Anyway, there are even free WebDAV clients AND servers. Its built into Windows and there are MacOS clients available for free. Its got IETF's blessing. It works. I'm no stickler for always using older techology but in this particular case, it would really be interesting to hear a solid technical reason why this particular use case needs a new, incompatible standard.
Maybe someone should just build a Javascript dav client, that would probably end the discussion actually given Windows support.
Posted by: chad | January 24, 2007 10:28 PMHi Guys, I am the CEO of Omnidrive, thanks for the comments. Interesting discussion here on WebDAV - funnily enough up until around a year ago when we started developing our own protocol, Omnidrive was webdav only. Even today, if you are using IE you can read/write office documents directly to/from the browser using WebDAV, so even though we dropped it as our primary protocol we still retain some of it - and we plan on bringing full WebDAV support back in (though with some caveats).
As for the reasons why we need a new set of web services protocols to define how data is interchanged between application rather than WebDAV, here is what we found and how we made our decisions:
1. This has been mentioned, but I will add to it as well, that WebDAV doesn't have a reference implementation. We were never able to find 2 servers or 2 clients that would be the same and our WebDAV server code ended up having hundreds of cases that were unique to different clients that we put in as work-arounds
2. The WebDAV protocol itself is just an extension to HTTP - one might ask though if the header extensions are necassery (such as PROPFIND and PROPPATCH) since you can achieve similar results with the standard HTTP/1.1 headers (GET, PUT, POST) and an RPC/REST like API interface. So the point there is to look at WebDAV vs HTTP - and if you compare the two of those then HTTP wins hands-down as it is ubiquitous and the standard is clearly defined and implemented. HTTP support in client libraries, web servers etc. is multiple times stronger than webdav support (mod_dav is a buggy hell-hole that hasn't seen development in years and doesn't offer much, it also hasn't fully implemented WebDAV)
3. The reason why you can't write a WebDAV client in Javascript is because XmlHttpResponse() is a HTTP function, not a WebDAV function, so it can not make WebDAV requests (eg. the extended headers, propfind, proppatch etc.). Javascript offers no way to make WebDAV requests and probably never will, as it will open up a whole new can of worms wrt security (the same can of worms that was opened when XhmlHttpResponse() became popular). While Microsoft did build some WebDAV support into IE (well, actually, built it into office - if you have web folders its because office put them there) they didn't extend to far in it's support because of the various issues that would arise.
4. Firewall issues - many firewalls will only let GET POST and PUT pass through - with WebDAV we bumped into this more often that we thought we would.
In summary, while WebDAV seems to be well supported, compared to HTTP it is just a baby. The reason as to why it wasn't adopted fully are long and we could talk about that for days - but I would say that one of the main reasons is because HTTP/1.1 was found to be sufficient, and local networks/company networks always had SMB and VPN's for file access and didn't need to go over the web.
Now that we would like to extend how far we can reach and grab our data we must look at what is the protocol this should be based on. To break data out of harddrives and devices and have it accessible on the web and everywhere we have to replace the SMB/VPN model with a web services model. The answer isn't WebDAV, since there are too many roadblocks, the answer is HTTP.
So we take HTTP and we implement a protocol within it that works like WebDAV/SMB but at the same time offers extensions with more features so that we can also use the protocol to read/write into web apps and so that you can take any source or destination of data, regardless of where or what it is, and have a common interface to it (eg. your local storage, your phone storage, your webmail, your contacts list, and every other web app will all be seen as the same thing with an HTTP-based protocol since standard interfaces are defined).
So we are working on defining these standard interfaces, and using our position as an open platform to promote them. This isn't about just Omnidrive, it is about offering our users the ability to transport their fixed-data (eg. files) anywhere and through anything.
An example of this is as follows, Omnidrive can take a folder on your desktop, a folder on your cell phone, a folder in your gmail, a feed from flickr and a podcast feed and bring them all together into one place. They all have standard interfaces that Omnidrive can understand. On the desktop, it is the Omnidrive client that takes your local storage and puts an interface on it. So right now we can work with RSS, Atom, APP, and our own extensions. We hope to marry these standards into one full standard way of working with web-related data.
Oh, and thats why we don't use WebDAV :)
Posted by: Nik Cubrilovic | January 24, 2007 11:36 PMHTTP is ambiguous, not just in servers but there has been a lot resolved
I believe that a REST API is essential these days.
Alex
Posted by: Alex Iskold | January 25, 2007 5:45 AMFair enough...anyway if something does come out of this, hopefully its simple enough that lots of interoperable implementations can be created.
Posted by: chad | January 25, 2007 9:42 PMI certainly understand the dilemma Nik faces, and the decision to 'roll your own' seems sound. But it also seems like a lost opportunity-- not so much for Zoho, but for WebDAV.
It was the right solution, but because it *didn't* have backers interested in enforcing it as an actual standard, you end up with the situation Nik describes-- no reference platform, firewalls that block non GET/POST/PUT and slightly different client implementations by the hundreds.
However, did you consider taking up the WebDAV banner and working within the spec and changing only the things you had to, like PROPPATCH issues? I'd wager there's a community waiting to jump on board that might add momentum. Though being a champion has its own set of problems.
Posted by: John Milan | January 25, 2007 9:48 PMAlso, the WebDAV interop issues aren't THAT bad. I have for instance used the jakarta server implementation with the Microsoft Explorer client and it works.
Posted by: chad | January 26, 2007 8:07 PMIf 'data portability through open standards' ends up acting / looking / performing anything like J2EE, just shoot me now. Good riddance, J2EE.
Nothing I ever did, or tried to do, in WebDAV worked. Not development/integration. Not configuration. Nothing. Good riddance, WebDAV.
As for Google "routing around of microformats in things like Google Base", I don't think, based on my limited understanding of microformats/gdata, that this was/is the case. To me, it seems like microformats are like toys - little data widgets - a small collection of xml schema maybe, but not much more.
GData, on the other hand, seems like an industrial strength data interchange protocol - formats, mechanisms, etc. In other words, the two technologies seem more complementary than antagonistic (right word?). To the extent that they interact at all, they will interact well. Microformats will sit on top of GData - maybe via simple XSLT. GData and Google Base are concerned with storing your data and getting it to you and back. If you want to expose microformats, good on ya, but that's largely irrelevant to GData.
Microformats, as a 'humans first' technology, was already starting with one hand tied behind its back - if only from a marketing perspective - if it wanted to be taken seriously as some type of data interchange format/protocol. Data protocols still require efficiency.
I found it odd that I hadn't even heard of a brewing 'microformats controversy' of sorts, but after reading some more, I think I know why - Google has been pretty darn open, and folks like me at least _want_ to believe that Google is not evil like Microsoft. As evidence of the former, there are literally thousands of mashups already written to google apis, and many thousands more on the way - and nary a complaint from the world-wide dev community. I never had a problem, in writing my mashups, with Google being secretive about anything, or non-standards-compliant about anything. Google has gone to some lengths to explain the reasoning behind gdata on their 'gdata intro' page - and it makes sense to me.
It seems like Google needed to conquer the world, but they needed a platform upon which to take on that task. That platform didn't exist. They had a choice - either do what needed to be done (gdata), or tell their investors that they're more interested in some kind of hokey/feel-good 'community process' than they are in turning a profit. I'm not one to stick up for capitalism or corporations or competition, but I do admire organizations that are willing to step up and 'handle their business', even if three years of planning and cooperation could result in a slightly better first cut.
And when casual developers like me look at gdata, we see exactly what we want to see - terms we're very familiar with already (atom, rss, extensions, http, get, post, etc.), and we see api's being furiously developed in several languages/technologies (PHP, C#, JSON, etc.) - and that fury is an instant indicator to us of developer community buy-in. We feel comfortable. We're ready to code.
As for Google extending Atom, they're doing it within the extension framework. If we didn't want Google to extend atom, then we shouldn't have included an extension framework.
In other words, much ado about nothing. :)
p.s. the 'Comments' link at the top of this post (and probably all the others, too), doesn't work. there's no '' anchor.
Posted by: Peter | January 27, 2007 10:55 AM