Giter Site home page Giter Site logo

Keep unknown attributes about cozy-sync HOT 10 OPEN

cozy avatar cozy commented on July 19, 2024
Keep unknown attributes

from cozy-sync.

Comments (10)

jsilvestre avatar jsilvestre commented on July 19, 2024

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?

from cozy-sync.

jsilvestre avatar jsilvestre commented on July 19, 2024

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:$!!$

from cozy-sync.

frankrousseau avatar frankrousseau commented on July 19, 2024

@jsilvestre This is related to CardDAV, not CalDAV.

from cozy-sync.

m4dz avatar m4dz commented on July 19, 2024

I ask myself if the issue found by @hansbkk do not relies on #11

from cozy-sync.

jsilvestre avatar jsilvestre commented on July 19, 2024

@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?

from cozy-sync.

frankrousseau avatar frankrousseau commented on July 19, 2024

OK let's keep it.

from cozy-sync.

hansbkk avatar hansbkk commented on July 19, 2024

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 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!

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

from cozy-sync.

frankrousseau avatar frankrousseau commented on July 19, 2024

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:

  • 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.

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?

from cozy-sync.

hansbkk avatar hansbkk commented on July 19, 2024

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-)

from cozy-sync.

hansbkk avatar hansbkk commented on July 19, 2024

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!

from cozy-sync.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.