search

skarim / vobject

A full-featured Python package for parsing and creating iCalendar and vCard files
http://eventable.github.io/vobject/
254 stars 93 forks source link

vCard 4.0 #106

Open ghost opened 6 years ago

ghost commented 6 years ago

Are there plans to support vCard 4.0? It is published in 2011, so it is already rather old even though not a lot of clients support it yet. The new CardBook extension for Thunderbird does though.

https://tools.ietf.org/html/rfc6350

wpercy commented 6 years ago

I personally have no plans on implementing vCard 4.0. But that's the great thing about open source libraries! You, or anyone else with the desire to, can implement it and I would be happy to review it and merge it in.

ghost commented 6 years ago

Absolutely. Then lets hope someone with the skills and time wants to help and put the effort in. Thank you.

NicoHood commented 6 years ago

I just had a quick look at https://github.com/eventable/vobject/blob/master/vobject/vcard.py

The source is not that big and it seems not every vcard section is implemented. I might be wrong with that assumption. Do you think the implementation of v4 requires a lot of changes? It might be quite simple to add/remove a few attributes.

NicoHood commented 6 years ago

Here is an overview of the most important changes: https://tools.ietf.org/html/rfc6350#appendix-A

Does not look too heavy.

wpercy commented 6 years ago

@nicohood cool, if you think it’s worth implementing, give it a shot and I’d be happy to review your PR!

NicoHood commented 6 years ago

Currently I only use the library for reading the vcards, and its also possible to read v4 cards. So that is good so far. It may be worth to implement the grouping options. But I am not sure if I am going to use those. :)

tasn commented 5 years ago

@wpercy, I desperately need it as Radicale depends on it, and etesync-dav depends on that. So I may take a jab at it very soon.

I've already skimmed the code a few times, but before I jump head first into this rabbit hole, I'd love to get some more information from you as you know the code best. I think the main issue with vCard 4 support is that it subtly changes the format. Here's a short summary of the changes with some examples: https://github.com/mangstadt/ez-vcard/wiki/Version-differences So for example, this:

EMAIL;TYPE=home:johndoe@gmail.com

would change to:

EMAIL;TYPE=home;PREF=2:johndoe@gmail.com

Is this something that's controllable from the definitions/behaviour files, or is this too much of a breaking change and I would need to change some the core parts of vobject too? How about automatically using the correct definitions based on the vobject version? Is that easily doable? Got any pitfalls/things I should keep in mind when doing this?

I'm sorry for asking all of these questions. I'm happy to invest the time into implementing this if it's actually doable, I just don't want to jump in and waste my time only to realise I need to break everything in order to add vcard v4 support.

Thanks!

Edit: formal list of changes compared to v3 from the RFC: https://tools.ietf.org/html/rfc6350#appendix-A

wpercy commented 5 years ago

No apologies necessary! I appreciate you grabbing a sponge and helping out here. I definitely think it's doable - I would say the biggest thing is trying to maintain backwards-compatibility with vCard versions 2.1 and 3.0 so we don't break any existing implementations.

I think we should be able to do this purely from a definitions/behavior standpoint, but will do some digging later today and try to update here.

tasn commented 5 years ago

Thanks for your comments, and looking forward to seeing your updates.

As for maintaining backwards-compatibility: the test suite seems exhaustive, is it safe to assume that if the suite passes I haven't broken anything? :innocent:

wpercy commented 5 years ago

I would say that's a safe assumption, but I'll be sure to test it pretty exhaustively myself once you've submitted a PR.

tasn commented 5 years ago

I think we should be able to do this purely from a definitions/behavior standpoint, but will do some digging later today and try to update here.

Hey, did you get around to looking into it by any chance?

tasn commented 5 years ago

I finally got around to looking deeper into this, notes for myself (and anyone else who wants to help):

  1. Seems like it's indeed possible to just create a new behaviour file.
  2. The biggest compatibility issue between this library and vcard 4.0 is with PHOTO which supports data URIs and therefore contains a colon (probably not an issue) and a semicolon (is an issue for the current code) - though this seems to be very easy to fix.
  3. Since this library isn't strict when parsing, vcard 4.0 seems to be mostly compatible with the current vcard 3.0 implementation.

@wpercy, is it possible to please reopen this ticket so we have one place to consolidate notes and progress? I can keep my notes locally, but I'd rather have people see that progress is being made and maybe pitch in with some help/feedback.

tasn commented 5 years ago

Thanks.

pgnd commented 5 years ago

@tasn

but I'd rather have people see that progress is being made and maybe pitch in with some help/feedback.

I know you've posted re: v4 support here, in Radicale proj, and on your EteSync proj.

Have you moved fwd on resolving this? If so, where's best place to follow?

tasn commented 5 years ago

@pgnd, it's split by nature, as both vobject and Radicale lack v4 support (and I can sometimes implement workarounds in EteSync directly). So here is the place to follow if you care about vObject specifically, and EteSync is the place to follow if you care about EteSync.

As for an update on this issue: I've investigated a bit how vObject deals with the PHOTO field. It looks like it should be very easy to at least fix this one (as a first step for v4 support), though it'll also come with figuring out how to implement multiple behaviours for vCard (v3 and v4).

So in short: I have nothing really new to add here, but I am making (slow) progress.

tasn commented 5 years ago

Not sure how complete this is, but here's an example codebase that handles both 3 and 4: https://github.com/enesser/vCards-js/blob/master/lib/vCardFormatter.js

Will at least provide insights about the differences (no parsing though, just generating).

marekrost commented 2 years ago

(Un)fortunately, the specification of RDAP protocol has decided on jCard v4.0 (JSON vCard serialization) as their contact information storage format.

I found no decent implementation of RDAP data parsing for python so I've started on that. I will want to use vobject to store the vCard data so I guess I'm joining you guys on this task.