@rfc2822 I have found a way to get the logs of the working test account initialisation with socat (on the davical server)0_1451635479201_test
VCard 3.0 support
-
By RFC 6352 6.2.2 “CARDDAV:supported-address-data Property”, CardDAV servers MUST accept VCard 3.0 and only MAY accept 4.0. However, DAVdroid always sends VCard 4.
Strictly speaking this is a bug, but I will consider it as an enhancement to detect whether the server is VCard 4-capable and then choose the right format because most servers/clients understand VCard 4 today.
-
Is there a technical reason/design decision for DAVdroid to send/store V4 only? I was bitten by that yesterday, as another client I use to access my CalDAV/CardDAV (CardDavMATE) server of choice (radicale 0.8) would only handle VCard version 3. The on-disk data radicale generates from DAVdroid’s requests doesn’t look like it would require any VCard 4-specific features, though.
-
The reason is that I didn’t find a good iCal/VCard library (I tried several ones) until I found iCal4j. iCal4j, originally for iCal only, has a VCard plugin that works the same way and provided good results, so I decided to use it. Unfortunately, it only speaks VCard 4 and when I realized that VCard 3 was required (3 days ago), iCal4j-vcard was already completely integrated. So, the solution will be to either add another library or replace iCal4j-vcard by another library or extend iCal4j-Vcard to parse/generate VCard 3, but I will do so when other things are going round. This is why I consider this as an enhancement although it is, as by RFC 6352, a bug (standards violation) to not support VCard 3.
-
What I also noticed yesterday while hacking on radicale and CardDavMATE in regard to VCard 3.0:
When a client stores a record of the <b>EMAIL</b> type in a VCard , it might supply some kind of qualifier (I’m not familiar with the VCard lingo, so that’s probably named differently in the standard :)) like <b>TYPE=INTERNET</b>. If that’s the case, DAVdroid loses any such association like “work” or “home” for that record when syncing.
-
@jtru The VCard/Android translation is not 1:1 because of the different storage schemes (database column vs type list). See https://github.com/rfc2822/davdroid/blob/1e00ed217fcc8dab1244ea7e39a6f1d2c9f29c5c/src/at/bitfire/davdroid/resource/LocalAddressBook.java#L166 for Android → VCard and https://github.com/rfc2822/davdroid/blob/1e00ed217fcc8dab1244ea7e39a6f1d2c9f29c5c/src/at/bitfire/davdroid/resource/LocalAddressBook.java#L405 for VCard → Android. I think the translation should make sense in most cases, but I’m also sure that there’s much room for optimisation
Edit: wrong line numbers
-
VCard 3 will come soon
By using ez-vcard (again) -
Just out of curiosity:
With release 0.3 of DAVdroid you replaced ez-vcard with ical4j-vcard. Now you switch back to ez-vcard.
Why did you replace ez-vcard in release 0.3? Does ez-vcard have some disadvantages compared to ical4j-vcard? -
I wasn’t aware that VCard 3 would be needed and felt better with only “one” dependency (ical4j + ical4j-vcard) instead of two (ical4j + ez-vcard).
-
Ok, thank you for clarification.
Can’t wait to test it…