I would not remove attachments by default, just wait whether they cause problems first.
They have caused problems already. Handling the images in the VCards requires special attention and still doesn’t work with large images flawlessly.
i’m not really familiar with android development, so i don’t know what you mean by column.
The contact information is not stored by DAVdroid itself, but by the Android contacts provider (“the address book”) which itself uses an SQLite database to store the information. The tables and columns must be used exactly by the Android specification so the contacts information is exchangeable between all Android apps. There are some fields/record types that allow sync adapters to store “custom” data – I’d probably use such one for the original VCard.
i’d be happy with attachments or overly large images being dropped if there is some kind of confirmation if it actually happens (“Uploading these changes will drop an attachment to this contact (pictures-of-my-cats.ppt, 20MB). [Save anyway] [Abort editing]”).
Normally, a sync adapter like DAVdroid (basically, just a service) should not need a (blocking) user interface (if that’s even possible, haven’t checked yet). For instance, if one app (let’s say, Samsung Kies or some other remote control app) adds a contact to the contacts provider, DAVdroid should sync it to the server without user interaction.
I’m not really interested to go into the small print of rfc’s, but I can dig and perhaps I can find one or two lines that underline the main idea I’m trying to convey.
I have found this:
»However, if a client needs to make a change to a vCard, it can only change the entire vCard data via a PUT request. There is no way to incrementally make a change to a set of properties within a vCard object resource. [Yes, we already know this. But now the interesting sentence:] As a result, the client will have to cache the entire set of properties on a resource that is being changed.« — RFC 6352 (CardDAV) 9.1. Restrict the Properties Returned
This can be most reasonably interpreted as that it’s expected behaviour to retain all properties (even if there’s no MUST).
As for PATCH. It’s hard!
As it’s not within the scope of CardDAV, i won’t use it until there’s a) at least a draft specification for usage with CardDAV/VCards, and b) support from at least a few servers.
So yea, I’d be happy to have a chat about the details of the rfc’s and what their intended meaning is, but in the context of this ticket this is meaningless, because step 1 is to accept that it’s not about being compliant to the letter of the specs, it’s admitting you have a problem.
I admit that you (not you @bartv2 but all who are affected by this issue) have a problem. Personally, I don’t have one because I have enjoyed the removal of hundreds of useless X-Mozilla-*, X-Evolution-* etc. headers at every sync Maybe that’s because I’m a minimalist — I honestly didn’t have the idea that someone will be missing these headers. (And yes, I know that DAVdroid itself uses X-DAVdroid-Starred and this will be lost when updating the VCard by other, equally-behaving clients. I didn’t think that somebody would be missing these headers, too.)
I want other users to have a good experience of DAVdroid. But it’s not the best idea to tell me your feedback like “Look there! A f*cking critical bug, and it deletes all data! How dare you!1! Fix it NOW, you’re my open-source slave and have to work when I say so! And by the way, you’ll have to do X and Y and Z, too, otherwise DAVdroid is crap!” when the behaviour just works fine for me, because then I’ll of course solve the conflict of your interests and my interests by asking an independent judge – namely the specs (even if I could simply ignore your feedback as well as the specs – there’s no obligation that I’ll code for you, and by the way, you could also do it yourself if its that important for you).
So, after considering RFC 6352 9.1 (see above), I think DAVdroid really SHOULD retain all properties (meaning a higher priority than “nice to have” ).