Skip to end of metadata
Go to start of metadata


<p>This request for comments focusses on WebDav. WebDav stands for Web-based Distributed Authoring and Versioning and is a technique that makes it possible to manage documents (WebDav), calendars (CalDav) or even contact identities (CardDav) over the HTTP protocol. Zend Framework could have a server and a client implementation of these techniques. There are many implementations (CalDav, CardDav, etc.) that fall in the WebDav family so from now on I will refer to WebDav as "Dav" and use the name WebDav for pure document management.</p>

<h2>Implementation in Zend Framework</h2>

<p>As explained in the introduction there are many implementations of Dav which all have there purposes. Zend Framework should contain all of these implementations and in order to provide a solid and stable codebase the following RFC's should be followed:</p>

<li>RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) - <a class="external-link" href=""></a></li>
<li>RFC 2518 - HTTP Extensions for Distributed Authoring – WEBDAV - <a class="external-link" href=""></a> (this one is obsolete but we should still try to follow this for backwards compatibility).</li>
<li>RFC 3744 - Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol - <a class="external-link" href=""></a></li>
<li>RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) - <a class="external-link" href=""></a></li>
<li>RFC 4331 - Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections - <a class="external-link" href=""></a></li>

<p>Nice to have implementations would be:</p>
<li>RFC 4709 - Mounting Web Distributed Authoring and Versioning (WebDAV) Servers - <a class="external-link" href=""></a></li>
<li>RFC 5323 - Web Distributed Authoring and Versioning (WebDAV) SEARCH - <a class="external-link" href=""></a></li>
<li>RFC 5689 - Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) - <a class="external-link" href=""></a></li>
<li>RFC 5842 - Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) - <a class="external-link" href=""></a></li>
<li>RFC 3648 - Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol - <a class="external-link" href=""></a></li>
<li>RFC 4316 - Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties - <a class="external-link" href=""></a></li>
<li>RFC 5397 - WebDAV Current Principal Extension - <a class="external-link" href=""></a></li>

<p>Further more the implementation should pass the Litmus test suite which can be found here <a class="external-link" href=""></a>.</p>

<h2>Building on top of WebDav</h2>

<p>CalDav and CardDav follow the same rules as WebDav, they should be build on top of the above RFC's and should follow the following RFC's:</p>
<li>RFC 4791 - Calendaring Extensions to WebDAV (CalDAV) - <a class="external-link" href=""></a></li>
<li>RFC 6352 - CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) - <a class="external-link" href=""></a></li>

<p>Once the needed RFC's for WebDav are implemented, we could start working on CalDav and CardDav.</p>

<h2>Changes to make</h2>

<p>As you probably know by now, the Dav protocol works on top of the HTTP protocol. That makes Zend\Http a perfect candidate to work with. Some changes need to made in Zend\Http before that is possible though.</p>

<p>Currently Zend\Http is pretty limited. The request class only allows request methods that are defined in that class. This would be a problem for Dav since there are lots and lots of HTTP request methods such as LOCK, UNLOCK, PROPFIND, PROPPATCH, MKCOL, etc.</p>

<p>I'd like to start a discussion about the benefits that the current implementation of Zend\Http has over a more dynamic one. If I develop a protocol that works over HTTP and uses request methods like KISSMY, I'd like Zend Framework to support me in that and not limit me. The same goes for the header classes. I can see the use of certain Header classes (such as Cookie) but it is overkill to create a class for every header. Especially since most of the time the implementation of the classes are the same. A generic Header class would do here.</p>

<h2>Resource handling for a Dav server</h2>

<p>Of course a Dav server needs to get it's data somewhere. For WebDav this could be the file system or maybe a virtual file system (Zend\Vfs anyone?), CardDav and CalDav information is most likely pulled from a database. My idea is to create certain adapters in order to give the user full flexibility of where to get the resources from.</p>

http http Delete
dav dav Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Apr 10, 2012

    <p>I would love to see this component become a reality especially the CalDav & CardDav.</p>

    <p>im guessing that i will have some free time in a few weeks after we released our homepage so maybe then we could get started on it together if you want any help?</p>

    1. Apr 11, 2012

      <p>I did lots of work on it already which I will commit to GitHub later this week. Maybe we can evaluate what there is left to do and divide tasks. That would be much appreciated! <ac:emoticon ac:name="smile" /></p>

      <p>I would love to get some feedback from everybody about the proposal as well. Especially since changes have to be made in the Http component.</p>