On Thu, Feb 04, 2016 at 12:27:54AM +0100, chrysn wrote: > i might be missing something trivial, but i actually do wonder how > creation of a new calendar should go about. > > when i follow the instructions in the README and then open up davdroid > on it, /private/test presents itself as an address book. sure, were i to > open /provate/test in a client that does not rely on auto-discovery that > much, things would work out, but not with davdroid. > > (i'm not sure whether it would detect the type correctly if items were > to be present, but we can't assume that to be the case for new setups). > > my patch queue contains patches that (in a first patch) only report > D:resourcetype C:calendar or A:addressbook (and not both) when davdroid > detects a particular use case, and (in a second patch) adds support for > per-collection .calypso-collection config files that allow setting that > behavior. THere is already such a setting called 'is-calendar'.
E.g. my calendar collection contains the following .calypso-collection configuration file: [collection] # Advertise this collection as a calendar. If this setting is absent, # the # collection's content is inspected for a guess. is-calendar = True # Advertise this collection as an address book. Behaves in analogy to # is-calendar. is-addressbook = False It looks like the patch I'm using that added this support was written by you back in 2014: commit 69726bcb92a7aad177eb3af3cae1aa3302347a63 Author: chrysn <[email protected]> Date: Fri Apr 4 13:24:40 2014 +0200 add per-collection configuration this is necessary to support empty calendars/address books with clients that rely on autodiscovery. pre-existing collections need per-coll Cheers, Jelmer
signature.asc
Description: PGP signature
_______________________________________________ Calypso mailing list [email protected] http://keithp.com/mailman/listinfo/calypso
