Open bnjbvr opened 10 years ago
jsilvestre
commented
10 years ago 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?
jsilvestre
commented
9 years ago Ok @hansbkk reported us something which is basically this issue:
Wow this is a big one! Every one of the IM handles from Google's export gets just silently dropped!
X-AIM:AIM X-GTALK:gTalk X-ICQ:ICQ X-JABBER:Jabber X-MSN:MSN X-QQ:QQ X-SKYPE:Skype X-YAHOO:Yahoo
Workaround would be to enter these in notes only.
Cozy exports them (Twitter & Skype only) as:
X-;TYPE=TWITTER:@AAAFirst X-;TYPE=SKYPE:AAFirstAAALast
and in fact Cozy uses the 'blank' "X-" label for company, all relationships, custom dates
rather than the more useful labels allowing grouping: item10.X-ABDATE:2019-12-31 item10.X-ABLabel:Arbitrary Date
and
item12.X-ABRELATEDNAMES:Big Brother item12.X-ABLabel:$!!$
frankrousseau
commented
9 years ago @jsilvestre This is related to CardDAV, not CalDAV.
m4dz
commented
9 years ago I ask myself if the issue found by @hansbkk do not relies on #11…
jsilvestre
commented
9 years ago @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?
frankrousseau
commented
9 years ago OK let's keep it.
hansbkk
commented
9 years ago 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)
there is no way we can guess every single custom fields clients will add there is not a perfect solution vCard: we currently support 2.1 and 3.0 in import, but we export to 3.0 only. And yet we don't fully support the standard anyway. We have also implemented some specific apple/google/android/.../ cases we can't actually guess every single X-field from every single provider. Even doing it for the main providers represents a huge work (which is why we don't support all of them yet).
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 https://github.com/cozy/cozy-home/issues/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!
The real problem here is that there is no complete vCard implementation in JavaScript
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?
it's not the best solution to sync .vcf on the disk, because it's just not how Cozy works. All the data are kept in the "data system" (which is basically a database with permissions, using CouchDB to store the data themselves).. . .
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.
The synchronization itself in Cozy works pretty well, the real work is in the vCard support.
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?
I suggest you open a new issue (https://github.com/cozy/cozy-sync/issues) for all each property you want us to support, so it is easier for us to prioritize.
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 the last very "light" and more flexible: http://radicale.org/technical_choices/#idid14
sync tools: http://github.com/untitaker/vdirsyncer http://ntbab.dyndns.org/apache2-default/seite/contactsync.html
Android dialer/editor: Contacts VCF
web-based editor: CardDavMATE
frankrousseau
commented
9 years ago 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?
hansbkk
commented
9 years ago 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-)
Because VCard is a good standard, we try as much to stick to it by providing two services: A service to allow to import contacts in VCard format. A service to allow to export contacts in VCard format. Both services can be used by external services.
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.
About the day to day contact management, it can be performed via the web UI or via smartphone through CardDAV protocol.
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-)
hansbkk
commented
9 years ago 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.