ownCloud and sabre/dav
sabre/dav (or SabreDAV) is the most popular WebDAV/CardDAV/CalDAV framework for PHP. It is open source and developed by fruux, a German company developing a unified contacts/calendaring system that works across platforms and devices. ownCloud builds on sabre/dav for its WebDAV, CalDAV and CardDAV support and is looking into even deeper integration. In a conversation with […]
sabre/dav (or SabreDAV) is the most popular WebDAV/CardDAV/CalDAV framework for PHP. It is open source and developed by fruux, a German company developing a unified contacts/calendaring system that works across platforms and devices. ownCloud builds on sabre/dav for its WebDAV, CalDAV and CardDAV support and is looking into even deeper integration. In a conversation with the core team working on the file management side of ownCloud, Thomas Müller, Robin Appelman and Vincent Petry, we explored sabre/dav and its value for a project like ownCloud.
WebDAV and sabre/dav
Frameworks like sabre/dav aid in building functionality. WebDAV, a http-based protocol built to deal with remote ‘resources and collections’ including files, appointments and contacts, offers all basic operations for handling data over the web. Vincent explains that “if you want to support WebDAV you’d have to write a lot of code yourself, like parsing XML; knowing what answers to send.” But sabre/dav can do the heavy lifting. “If something requests a file, we just send a file. We don’t have to care too much about how WebDAV works.” Robin adds that “it does the implementation before the call itself; not the logic but just the WebDAV protocol.” Actions like downloading a file or receiving the contents of a folder are handled by sabre/dav using the WebDAV protocol. The decision about what data to grab or the folder to present, however, is a decision made by the ownCloud code.
fruux offers some more technologies in the sabre/ family including sabre/vobject, sabre/http, sabre/xml and other libraries. These are used in sabre/dav itself, as well as useful stand-alone tools.
ownCloud and sabre/dav
sabre/dav was introduced into ownCloud 3, but WebDAV has been supported since “the beginning” explains Robin, but “that was with a different library.” It was what he called “a complete implementation;” implementing both protocol and the logic behind it, on top of the normal file system of a server. This means ownCloud had no control over where the files were stored or how they were named. But ownCloud “has its own file system layer which allows us to mount the external storage, do sharing and all kinds of things.” sabre/dav, however, allows better integration. With the old implementation, Robin notes that “we were forced to make changes to the library; to let it call our own functions instead of its internal.”
Another benefit of sabre/dav is that with it, as Thomas points out, “we have the possibility to easily extend the protocol to our own needs;” one of the great advantages of WebDAV. “For example, we have our own properties we communicate via the protocol like the file ID, the permissions, if a user can read a file, or if the file is shared.” With the new version of ownCloud 8, tags are handled over the WebDAV protocol as well. This flexibility in WebDAV, exposed through sabre/dav’s plugin system, is important. For the synchronization by the desktop client, there is additional information required to properly sync, such as the FileID and information like sharing state or write permissions so that the client can show the proper overlay icons in the file manager, restrict edits to files and so on.
Porting to sabre/dav
Porting our old code was fairly easy according to Robin. “The basic implementation is fairly small,” he says, “because it is just an adoption between one API, from sabre/dav, to another– ours.” sabre/dav is “meant to do your own thing on top of WebDAV,” he adds. Vincent also points out that “it has a plugin system. For example, for the tags we wrote a plugin that would add an additional attribute without having to change the main code.” Robin agrees, stating that “sabre/dav is built from the ground up to be modular, to allow users of the library to extent on top of it.”
The only difficulty with sabre/dav was with performance. This was “related to the way sabre/dav reads the properties of the file system.” Elaborating, he explains that “internally, sabre/dav just iterates over all the files in a folder,” requesting the meta data for each file separately, “which was fairly slow, as you can imagine.” For each call, ownCloud had to go back into its database or even request the information from external storage. ownCloud can request all metadata in a folder at once, but sabre/dav did not support this. It was solved upstream, however, in sabre/dav by making it possible for sabre/dav to notify that it wants the metadata of the folder. Robin concludes that “adapting the API’s was easy. But also adapting the API’s in a way that is also fast, is harder.”
Of course this isn’t a sabre/dav issue per say, because “two API’s are never the same,” Robin notes. “In order to implement one API in another, you have to do it in an inefficient way because they are almost never on the same level.” Vincent adds that the problems “are solvable now,” as the incompatibility has been dealt with following the improvements. “In future versions of ownCloud, we can clean up the code and do things the proper way.”
To be continued!
Read part II here.