andrew at morphoss
Jun 19, 2012, 3:05 AM
Post #2 of 4
(755 views)
Permalink
|
On Tue, 2012-06-05 at 12:18 +0200, Matthias Althaus wrote:
> Hey there,
>
> so my calendar package is quite done and we're doing a first rollout
> on our testing servers this week. As my boss likes to reduce
> everything to a minimal afford, we played around with the Calendar
> auto-discovery stuff. So far I understood the RFC (drafts) this is
> either accomplished by the well-known URL or a SRV entry.
Both well-known URL and SRV apply. SRV does not provide path
information on the server, so you might still need to
do /.well-known/caldav handling. In general I think it is more
important to support /.well-known/caldav than SRV.
> At the moment we only have two apps to test this: iPhones and
> Lightning. ^^
>
> 1) The iPhone is checking well-known and doing some magic
> afterwards... there it's getting the home collection and my boss is
> happy.
>
> 2) I tried to tell Lightning to check cal.example.org (which redirects
> everything to the caldav.php), but it's not working out. It's doing a
> PROPFIND to that location and stops as it didn't find a collection. So
> I guess that Lightning isn't able to discover the user's home
> collection on it's own?
>
> 3) For Android you need a 3rd party app like aCal, yes?
Right. You can install aCal through f-droid.org also.
I know the process aCal follows quite well, so it might be useful to
fully explain it to you...
Depending on how aCal is built, it may do SRV queries for
_caldavs._tcp.domain.tld, but in general it is built without SRV support
(it bloats the app by +50% to include this!). After that it will try
and detect likely ports on the server (443, 8443, 4443, 80, 8008, 8080)
and once it has a list of those it tries each port to see how far it
gets in discovering a CalDAV server, and in particular a principal-URL.
Ideally the /.well-known/caldav works and everything is away, but
failing that it attempts to PROPFIND on the path it was given, and then
on '/' as a last resort.
It has now collected a set of information, and picks the first one which
is SSL which provides a principal-URL, or failing that, the one which is
insecure... making that last choice is hard if there's nothing obviously
correct, but we're probably screwed in that situation anyway.
Once it has a protocol://domain:port/path for the principal-URL it does
a PROPFIND looking for the calendar-home-set, then another PROPFIND to
discover the calendar collections. A similar process is followed for
addressbooks.
Finally, once it has the calendars it begins to synchronize the data
from the calendar into a local cache. For each calendar it starts this
off with a calendar-query for a range of dates including a period from
two weeks in the past to 6 weeks in the future and starts to populate
it's internal cache with that data. It then attempts a PROPFIND on the
calendar to get the full list of resource URLs for the collection, and
uses (a series of) calendar-multiget reports to fetch the actual data.
Once the resources in the calendar are up to date it switches to using
WebDav synchronisation to (hopefully) minimise the ongoing data use.
That's the *ideal* process, but things can go wrong, like if the server
does not support calendar-multiget we fall back to a series of GET
requests, or if the server does not support sync-report we just do the
PROPFIND request all the time. There are probably better heuristics for
some of these failure modes, but I'm not sure I want to complicate that
further!
> 4) The magic that you can tell Google which calendars you want to
> access through CalDAV, so that you don't have to add one by one, is
> nothing I can find in any RFC?
I think you mean this?
https://www.google.com/calendar/iphoneselect
That's not in any RFC, it's purely something that Google does. Once you
go through that process, aCal will also happily discover all of your
Google calendars though.
Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
The longer the title, the less important the job.
------------------------------------------------------------------------
|
signature.asc
