caveman+davical at caveman
May 18, 2012, 11:14 AM
Post #3 of 6
On May 16, 2012, at 9:30 PM, Andrew McMillan wrote:
> On Wed, 2012-05-16 at 14:15 +0200, Matthias Althaus wrote:
>> Hey guys,
>> after getting the basics done, I'm looking into stuff for further
>> extensions. One thing will be the subscription of external calendar
>> sources (ICS, not CalDAV). So I found the wiki page about external
>> I added a DoBINDRequest() method to my version of caldav-client.php
>> and can generate the request... that was the easy part, but I don't
>> get how to use the BIND then. I looked into the code and found that
>> he's using some "'/.external/'.md5($href)" container.
> As I understand it the remote data is pulled into a local cache under
> this URL, with the idea that if several people subscribe to the same
> remote URL they all end up seeing the same single collection.
Correct, for example, if 5 users on the same server all bind the exact same external url only one copy will be created in the database. Internally this is stored with a dav_name of /.external/ + MD5SUM of external url. Initially I did it that way so that importing the remote calendar, which is pretty intensive on the server side, didn't need to happen on every request to the bound collection.
All of the client interaction should be with the bound url which would be specified by the segment name. Slightly modified from the wiki:
<?xml version="1.0" encoding="utf-8"?>
would create a new collection at
>> So how does this work together with the "BIND
>> https://example.org/caldav.php/user/"? Can I query the collection
>> under "https://example.org/caldav.php/user/.external/somemd5"?
No, you shouldn't ever see the /.external/ url's those should never be exposed to the client(via CALDAV), if you can than that's a bug.
> In general it should look like a normal collection to a CalDAV client,
> though a read-only one.
It's a little odd, but the contents are read-only, the properties are not, because the properties are on the binding not the remote contents.
>> Would be great to get some more insights on the topic... :D
> I don't use this myself, but there are some commits recently where
> people have sent me some fixes for this functionality, so it looks
> likely that Rob didn't consider everyone's circumstances originally :-)
Additionally, I recently discovered a race condition where the contents of the remote resource are never actually retrieved/stored. I'm working on fixing that as well as adding a few extra things that should add some flexibility for the future.
Hopefully that explains what currently happens.
rob [at] boxacle
DAViCal-dev mailing list
DAViCal-dev [at] lists