This is part two of a conversation with ownCloud core developers Thomas Müller, Robin Appelman and Vincent Petry, where we explored sabre/dav and how it is used within ownCloud. We discussed WebDAV and sabre/dav in the previous post, ending with how it ended up in ownCloud. Today, we’ll discuss where ownCloud and sabre/dav are going now and in the future!
Collaboration upstream
As noted in part 1, ownCloud developers have worked with sabre/dav to improve the performance of showing folder contents. This isn’t the only place where ownCloud and sabre/dav worked closely. There has been a variety of contributions from ownCloud to sabre/dav but sabre/dav team members have also been giving input on ownCloud code and solutions developed in ownCloud. According to Thomas, the lead sabre/dav developer at fruux, Evert Pot, “is really a nice guy. He is technically highly skilled, especially in WebDAV and PHP and everything around. And he has always been helpful over the past years.” He adds that “this is one of the reasons we stick with sabre/dav. A good relationship with upstream is “very important,” Vincent and Robin agree.
Vincent notes that “he seems excited about how we use sabre/dav.” He speculates that “we might be one of the projects that use the framework in a very deep way; we probably use most of the features of sabre/dav.” Thomas adds that “we use it extensively, but any PHP based group ware also uses sabre/dav. Horde has it, group office has it.” ownCloud is among a big group of open source projects that use sabre/dav, and everybody agreed that the project is important for the “PHP and open source ecosystem.”
It is good to see that ownCloud embraces the open source process. Various ownCloud contributors helped sabre/dav out in the code department, like here, here, here and here.
When asked, Dominik Tobschall from fruux had this to say from their side of the collaboration:
“It’s great to see projects like ownCloud adopting sabre/dav. While we have plenty of users, the most valuable users are the ones that contribute back. We highly value thinking about the future together. By cooperating we can create a stronger product for everyone. An active community is really vital for any open source project. It benefits every implementor, not just of sabre/dav, but also our various spin-off projects, such as sabre/vobject (a library for parsing and manipulating vCard, iCalendar, jCard and jCal), sabre/xml (the only XML library that you may not hate), and many other projects we work on. Last but not least our own end-user product fruux -a unified service to manage contacts, calendars and tasks for consumers and teams- is also built on top of our open source technologies. Open source is not just a major part of our strategy, but also what we think is the right way to build software.”
Future of WebDAV in ownCloud
Vincent will be part of the work to update sabre/dav in ownCloud to version 2. It requires some “cleanup and re-factoring,” but stands to make “our code more beautiful.” The upgrade will be preceded by “adding unit tests everywhere to make sure the upgrade is smooth.” Vincent notes that the team is also looking into using sabre/dav on a deeper level, “not just files, also for other things like tags and users.” It is possible because Microsoft uses WebDAV for email and contacts as well. Thomas points out that ActiveSync is a “perverted form of WebDAV, using a binary form of XML.”
Vincent calls their thinking around WebDAV usage a “research project.” Thomas states that “you have crazy ideas, inspired from nowhere, but also from Evert himself”. He explains that “you grab 5 minutes and scratch some code together to see if it works properly. And discuss it and iterate.” He describes parts of the current API as needing a cleanup, something the team has been thinking about for a while.
Vincent describes how ownCloud has “multiple API formats. Internal REST API’s, OCS, WebDAV.” The team, however, wants to consolidate these formats and have only one solution in the end. In a GitHub discussion Vincent proposed to “drop WebDAV and move to REST.” At this point Evert “clarified that we can actually use WebDAV for things other than files,” which opens up new opportunities. Vincent wasn’t aware that WebDAV is that extensible, and the team is now thinking about putting in even more effort in to WebDAV, rather than less.
This is an example of how the team works with sabre/dav and fruux, Evert in particular to which Thomas notes is “mainly on GitHub where we know this is a WebDAV issue and where we know we need his expertise. We just directly ping him– ‘Hey Evert, can you have a quick look?’ And he’s usually responding really fast. It’s an awesome collaboration with fruux, I have to say.”
Conclusion
When asked what would have been great to know before starting to use sabre/dav, Thomas simply says “nothing.” He elaborates, explaining that “there are good examples and good documentation, and because of the power of open source there are at least two or three other projects that also use sabre/dav, so you can see how they do it. From my point of view it is quite self-explanatory.”
Vincent also points out that he “started using it later” and didn’t know “WebDAV is so extensible and that you can use sabre/dav for that, not just for files.” It was the function names that “misled me,” he adds, but with version 2 “these are more generic.”
Thomas and Robin both agree and Thomas notes that “you can extend it to almost anything, which is the power of the protocol itself, like Microsoft uses it for email.” Comparing it to other API’s, he points out that “you can avoid using a nightmarish, ancient protocol like IMAP.” WebDAV is “almost ‘REST’ful,” and its “simplicity, yet flexibility helps you design proper API’s.” A first version of any API “goes mad” but with a “proper concept and mechanism” you can build a good API.
The team is looking forward to deeper integration with WebDAV in ownCloud through sabre/dav, and the benefits it brings – “beyond just code.” The good collaboration with upstream, not to mention the well designed code itself, has proven to be inspiring.