Keep unknown attributes #26
Comments
|
Reminders support is going in the next version. About keeping unknown attributes, it's not something planned anytime soon. I think we're going to slowly improve our iCal support, but the next version is going to bring the most used ones. Can we close @bnjbvr? |
|
Ok @hansbkk reported us something which is basically this issue:
|
|
@jsilvestre This is related to CardDAV, not CalDAV. |
|
@frankrousseau yes the specific example is for iCal, but the problem is generic to both iCal and vCard, and since the issue is already open here, I thougth it'd be better to do the follow up here. Do you want me to move it? |
|
OK let's keep it. |
|
OK, after reviewing the issues created out of my input
This one is the most "general", so I'll use this for further notes along those lines, and if you guys see speciic issues more suited to a different place split them off as above. Quotes from email (not sure if they also reside elsewhere here on git)
I am not a programmer, and don't understand the underlying protocols even as a user. However I believe all the tools I suggest you check out in cozy/cozy-home#287 have as a goal full fidelity as much as possible, to preserve whatever vCard information the user entrusts to the projects software. Maybe the problem is due to the apparently focus on CardDAV, as opposed to vCard. The latter is just a text file, don't try to transform into your predefined database fields, just keep it in sync as a vCard, why bother trying to understand the contents if your job is just to sync it? Now of course if we're talking about the web-based editor functions, open/edit/save changes, there you can warn the user that not all his content is being displayed as structured fields. Ideally present in plaintext form that data for editing within the notes field - see what Google does with a custom field on vCard export for a good example. But don't just silently drop/delete ANY of the user's precious data!
I would think this is only relevant to the user-interface side right? Stuff like sync that has no UI can use whatever code/language you choose, correct?
Well as a user I only care about results, not how you get there. If "just" sync'ing vCards is what is needed to preserve my precious data - the latter is infinitely more important to me as a user compared to "loyalty" to a particular choice of software, if you strip out all my contacts' birthdays or relations or URLs I'm just going to say "FAIL" and move on to another project that puts my needs above some abstract architectural principle.
That make no sense at all to me. What it is that I need sync'd is my existing data, whose canonical form is folders full of vCards. CSV doesn't work nearly as well - what other container is there? Unless A. you are suggesting Cozy users should always be starting from scratch entering their contact data into your UI and be willing to forego using features/fields they are used to in their other contact applications? or B. you plan to somehow support directly retrieving the user's data on their behalf from Google, syncevolution, Thunderbird etc?
Well my current project is choosing a contacts sync-server platform that preserves all my contact data, so chances are I won't be coming across more issues in Cozy in the near future. Unless I bypass your CardDAV. and just use a plain file-sync support like WevDAV to host my collections in vCard format in conjunction with the other tools I cited earlier. Actually I will repeat the list again here for emphasis - you really should IMO investigate their functionality for ideas on how to fully support your (prospective) users' existing contacts data. servers: SabreDAV (used by Owncloud and many other projects), DaviCal, and Radicale sync tools: Android dialer/editor: Contacts VCF web-based editor: CardDavMATE |
|
Thank you @hansbkk for your precious feedback. It will help to improve the Cozy support of CardDAV. Cozy is designed to store everything in database and avoid files when it's possible. That allows every Cozy application to share information easily. The raw VCard format is very painful to deal with for a developer. Moreover, managing it in a different way than other data complexifies the application code. It's our design choice to not store Contact information as file. This choice has the drawbacks you noticed, but we won't change it. Because, the philosophy behind Cozy is to provide a datastore fully interoperable via a REST API (set of urls that provide services) not via files. Because VCard is a good standard, we try as much to stick to it by providing two services:
Both services can be used by external services. About the day to day contact management, it can be performed via the web UI or via smartphone through CardDAV protocol. Does it make things clearer? Could it fit with your use case? |
|
Yes I understand your design choices, just wanted to emphasize that these are not important to your (prospective) end users when discussing functionality they require. In this case the design decision seems to make supporting the above stated goals more difficult, but of course that is also "your problem" to be blunt 8-)
So the challenge becomes, when I import data set A into Cozy, refrain from making any changes there and then export to data set B, keeping full fidelity between the two. The ordering of fields in the text file is irrelevant, not significant at all. The choice of format over the field label isn't critical in itself, so if the B output is "more compliant" with the standard that's fine as long as this format is accepted by the major implementations. As stated earlier, sticking to the "google way" is probably safer for the real world.
Well few Android contact tools support all the Google Contacts fields, the phone-native app varies greatly from one manufacturer to the next. "Contacts VCF" is an exception, as that actually uses vCards as its native data store. Which is why having full support for them in the web-based editor - as CardDavMATE/CalDavZAP and OwnCloud's do - is important. Otherwise on the desktop, I only heard of Khard https://github.com/scheibler/khard/ Thanks very much for your attention to these details - it's the edge cases that push for excellence in a project 8-) |
|
I've been experimenting with the contact editor in SabreDAV - whatever version's driving Fruux.com - and have been very pleased. pretty complete implementation in the GUI, extensions seems very close to Google/Apple's plus add a few - nice use of "show as" checkbox to toggle a person <-> company card if you use a label they don't include in their GUI they will add it to their list for that field best of all if they don't recognize something they leave it alone! note haven't yet compared to Owncloud's nor CardDavMATE Also vdirsyncer, excellent tool! |
When adding an event that contains CalDAV attributes that are unknown to Cozy, they are deleted by default. While cozy/cozy-calendar issue #97 is not mandatory, this one would be sufficient to use only cozy (and get rid of my owncloud instance for realz \o/). I guess you could set up a member of Event that would contain a String attribute "others" or something like this. I can do it if you want, but I might need a lot of help for finding all places that need changes!
STR
Expected
When synchronizing with the cozy instance, the reminder should be kept (even if the cozy calendar doesn't handle them).
Observed
The reminder is "forgotten" during the sync, i.e. the event doesn't have a reminder after a sync.
The text was updated successfully, but these errors were encountered: