Calendars and Address Books Discovery MechanismsCalendar and address book folders, as well as your principal items, could be located anywhere in your server folders hierarchy. To assist client application in finding these CalDAV/CardDAV folders and detect server features, your server may provide several discovery mechanisms. With discovery mechanisms, you will specify only the root of your server while the server will provide information where calendars and address books are located.Note that even though some discovery mechanisms are optional, iOS and OS X requires ALL discovery mechanism described in this article to be supported.Below we will describe how discovery works. On the picture below you can see items that participate in discovery process and interfaces that they must implement:The numbers specify a typical request sequence during discovery. Note that requests and their sequence submitted by various CalDAV/CardDAV clients may differ. The client application may submit additional OPTIONS and PROPFIND requests not listed here, that must be processed by your server for successful connection. Examine your WebDAV server log (WebDAVLog.txt) to see the exact sequence of requests that is specific to your client.Here are the major items that participate in discovery: Site RootIf you wish to enable easy location of calendars and address books your site root must process.well-known URI requests.
During this request, your server will return the Context Path Folder path. Context Path FolderContext path folder could be located anywhere in your folders hierarchy. This folder must return URL of the currently logged-in principal for further discovery of calendars and address books available for this user. User (Principal)Contains information about the user. During discovery process, the client application will request the location of the home-set folder on the principal URL.
Home-Set FoldersHome-set folders contain calendar folders and address books folders available for the currently logged-in user. The client application will list calendar folders and address book folders in every home-set folder returned by your implementation.Below we will describe the discovery requests that your CalDAV/CardDAV client can submit:.Context Path Discovery (.well-known Request)During this request the client request the location of ClaDAV or CardDAV root folder (context path). While the.well-known request is optional it is required by iOS and OS X Calendar. Here is an example of CalDAV request and response: PROPFIND /.well-known/caldavDepth: 0Authorization: Basic.HTTP/1.1 301 Moved PermanentlyLocation: /DAV/Client submits PROPFIND request to /.well-known/caldav or /.well-known/carddav URL. The server must return a redirect to the folder where CalDAV or CardDAV service is available, which is called context path. Do not confuse the context path folder with class – the later represents a WebDAV HTTP request on a server side.Typically you do not need to program anything to implement this context path discovery.
The Engine will call passing /.well-known/caldav or /.well-known/carddav path, and if your implementation returns null, the Engine redirects to the site root (‘/’).Note that in all CalDAV/CardDAV samples provided with the SDK and in code generated by the context path folder is a site root (the GetHierarchyItemAsync implementation returns null for the.well-known request). In this article, the context path is on /DAV/ folder for the description convenience.If required, you can customize the.well-known URI behavior, returning from GetHierarchyItemAsync call instead of returning null. Below you can see the sequence diagram for these request:The returned IHierarchyItemAsync item must represent the context path folder on your CalDAV or CardDAV server. The Engine will request the property on the returned item and redirect to the URL constructed from it. Current User Principal DiscoveryDuring this request the client application requests information about the loged-in user (current user principal).
Below you can see an example of such request and response: PROPFIND /DAV/Depth: 0Content-Length: 181Content-Type: text/xmlAuthorization: Basic.HTTP/1.1 207 Multi-StatusDAV: 1, 3, access-control, addressbook, calendar-accessContent-Type: application/xml; charset=utf-8/DAV/HTTP/1.1 200 OK/DAV/acl/users/User1/DAV/acl/users/User1Here is the sequence diagram for this request:. Engine calls GetHierarchyItemAsync passing URL specified in the request (typically context path returned during context path discovery). Your implementation must return hierarchy item implementing. Engine calls ICurrentUserPrincipalAsync. Your implementation must return the logged-in principal implementing ICalendarPrincipalAsync/ IAdderssbookPrincipaAsync.
Vista Calendar Download
Your principal item will also implement /. These interfaces will be used during home-set folders discovery (see below) to query folders containing calendars and address books. The Engine calls IHierarchyItemAsync. Path on the principal item and returns it o the client.Typically this request is submitted on the context path folder, but could be submitted on other items too. Below you can see a table listing which item should process this request: CalDAV clientItems that must process current-user-principal requestiOS CalendarContext path folderOS X CalendarContext path folder, Principal itemeM ClientURL provided when connectingMozilla Thunderbird LightningURL provided when connecting (can be calendar folder URL only)Features Support DiscoveryThis request is sent by the CalDAV and CardDAV clients to discover features supported by the server. In the response, at a minimum, your server must provide 1, access-control and calendar-access tokens in the DAV header for CalDAV server or 1, access-control and addressbook for CardDAV server. Below you can see the example of this request and response: OPTIONS /DAV/acl/users/User1/Content-Length: 0Authorization: Basic.HTTP/1.1 200 OKDAV: 1, 3, access-control, addressbook, calendar-accessHere is the sequence diagram for this request for CalDAV server:.
The Engine calls GetHierarchyItemAsync passing path specified in the request (typically principal item path returned during current user principal discovery). Your implementation must return hierarchy item implementing and in case of CalDAV server or and IAccessControl in case of CardDAV server. Typically you will return item implementing / and ICalendarDiscoveryAsync/ IAddressbookDiscoveryAsync intrefaces that are derived from them. To form the DAV header the Engine will query interfaces on the item returned and include necessary tokens.
The Engine does not call any properties or methods.Below you can see a table listing what tokens are included depending on interfaces found on the item: Interface that must be implemented on an itemToken in DAV headerICalendarItemcalendar-accessIAddressbookItemaddressbookIAccessControlaccess-controlcalendarserver-sharingcalendar-auto-scheduleIn case of iOS and OS X this request is sent on the principal item. It could be also sent on other items.
Below you can see a table listing which item should process this request: CalDAV clientSent oniOS CalendarPrincipal itemOS X CalendarPrincipal itemeM ClientHome-set folder, URL provided when connecting, Principal itemMozilla Thunderbird LightningOne level above the calendar folder.Note that you can find the DAV header in other responses too. This is required to support Bynari Collaborator which fails to connect without this header. Home-Set Folders DiscoveryDuring this request the client application queries the location of calendars and address books available for the loged-in user.
I'm no coder, even though I can hack into a bit of code form time to time to get a tweak out of a module, but I do know there are some php classes and libraries out there form caldav already. The caldav server I run for myself is php, but it offers no web-based actual calendar system, just the dav backend.As a matter of fact, there isn't one single functional caldav enabled web-calender out there, unless you bundle in the server with something like Zimbra, Bedework, or the Cosmo server. I think that this functionality in Drupal would be absolutely perfect, it makes sense that it should be there. I really wish I knew how to implement it myself!. or to post comments.now that I think about it, we can go two different ways:1. Add support of connecting to 3rd party CalDAV servers and importing/syncing data.
This includes the risk of people asking support for every CalDAV server out there.2. Make it so that the Calendar module behaves as a CalDAV server itself (stores data according to the CalDAV standard + exposes that data in a url that people would direct their clients to).I wouldn't know about the technicalities involved in these two ways though. Or if they are possible at all. or to post comments.
Check out SabrDAVIt should be possible to wire that up to Drupal.SabreDAV allows you to easily add WebDAV support to a PHP application. SabreDAV is meant to cover the entire standard, and attempts to allow integration using an easy to understand API.Feature list:Fully WebDAV compliantSupports Windows XP, Windows Vista, Mac OS/X, DavFSv2, Cadaver, Netdrive, Open Office, and probably more.Passing all Litmus tests.Supporting class 1, 2 and 3 Webdav servers.Locking support.Custom property support.CalDAV (tested with Evolution, iCal, iPhone and Lightning).CardDAV (tested with OS/X addressbook, the iOS addressbook and Evolution).Over 97% unittest code coverage. or to post comments. I've been working on connecting a CalDAV server (probably SabreDAV) to my Drupal site.
I figured it would be fairly easy through Feeds, possibly with a script to export the data into a Feeds-compatible format (RSS, CSV) as needed.I haven't gotten very far on the project yet, but I'm very attracted to the idea of being able to pull the data into Drupal through this module. No hacked-together code!I was only looking at making my Drupal site.read. the CalDAV data - that, I think, is the highest priority.
(I can use iCal on the Mac as my primary client to make changes.) Second priority would be to allow the Drupal site to.write. to the CalDAV server. I wouldn't let that second priority stand in the way of releasing the first, though.Wish I had the chops to make it happen! I'd be very happy to do real-world testing if you can get it to that point. or to post comments. I have no idea.
I've been working on Date iCal during work time, since my company's website needs iCal functionality. But since Date iCal 7.x-2.x is essentially done now, I've been assigned to create another new feature of our site.So, I may be able to work in a few hours here and there, but I won't be able to dedicate my time to Date iCal like I have been over the past weeks.So, if you want CalDAV support, it would help me immensely if you could do the research for me on how to actually implement it. I'd never even heard of CalDAV before reading this ticket. or to post comments. Would definitely like CalDAV if possible - Google Calendar is quite popular. I'm not a programmer but did a little homework wich may be helpful:Drupal sandbox: (could be jackpot! May be interested in a collaboration?)-not sure about licensing but worth asking.- lots of resources for PHP dev.Some discussion on implementation:-list of clientsFound this page as a good overview of what it is relative to iCAL:Internet Calendar SubscriptionsAn Internet calendar subscription is simply an iCalendar data file made available on a web server.
However, rather than using a web browser to download the calendar data, calendar clients can instead use the URL to the calendar data on the web server to download the calendar data themselves. Additionally, the clients can check the web server on a regular basis for updates to the calendar data, and then update their own cached copy of it. This allows calendar data that changes over time to be kept synchronized.CalDAVCalDAV is a calendar access protocol and is defined in RFC 4791 6.
The protocol is based on WebDAV which is an extension to HTTP that provides enhanced capabilities for document management on web servers.CalDAV is used in a variety of different environments, ranging from very large internet service providers, to large and small corporations or institutions, and to small businesses and individuals.CalDAV clients include desktop applications, mobile devices and browser-based solutions. It can also be used by 'applets', for example, a web page panel that displays a user's upcoming events.One of the key aspects of CalDAV is its data model.
Simply put, it defines a 'calendar home' for each calendar user, within which any number of 'calendars' can be created. Each 'calendar' can contain any number of iCalendar objects representing individual events, tasks or journal entries. This data model ensures that clients and servers can interoperate well.In addition to providing simple operations to read, write and delete calendar data, CalDAV provides a querying mechanism to allow clients to fetch calendar data matching specific criteria. This is commonly used by clients to do 'time-range' queries, i.e., find the set of events that occur within a given start/end time period.CalDAV also supports access control allowing for features such as delegated calendars and calendar sharing.CalDAV also specifies how scheduling operations can be done using the protocol, rather than, for example, sending scheduling messages via email. Whilst it uses the semantics of the iTIP protocol, it simplifies the process by allowing simple calendar data write operations to trigger the sending of scheduling messages, and it has the server automatically process the receipt of scheduling messages. Scheduling can be done with other users on the CalDAV server or with calendar users on other systems (via some form of 'gateway'). or to post comments.