Closed Bug 1774235 Opened 3 years ago Closed 3 years ago

Contacts webextension API should accept vCard properties as JSON

Categories

(Thunderbird :: Add-Ons: Extensions API, task, P2)

Thunderbird 102

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: BenB, Assigned: neil)

Details

Thanks, John, for having fixed bug 1773144. It's nice that you're supporting the old API and property names, because webextension APIs promise to work beyond TB versions.

Also, we should not require addons to ship a vcard text parser. That's just not a sane internal application API. It's the text representation of vCard that is the most painful and which requires third party libs to implement correctly.

As a consequence of that, there's a risk that devs will try to manually parse or generate vcard text format, to avoid third party libs, and then it works in simple cases, but it fails in more complex cases with umlauts and escaping, and the dev will not notice, but users will complain about strange bugs that can only be reproduced with the actual data of the end users. That's going to be a nightmare to debug.

I would prefer a third way, which is a gold middle between those:

Use the standard vCard property names and semantics, but in a JSON form. If we could return or accept vcard properties as JSON, in whatever specific form the vcard lib uses, e.g. for repeated values and parameters, that would be fine for me.

This allows to use standard property names, but doesn't require third party libraries for the complicated text parsing.

Implementation:

  • TB uses the existing vCard lib that it already uses internally, to convert between vCard text format and JSON, as TB already does internally.
  • The JSON / plain JS object form of the vCard, as the lib generates and accept it, is also accepted in the Contacts API.
Assignee: nobody → neil
Severity: -- → S1
Priority: -- → P1
Version: Trunk → Thunderbird 102
Severity: S1 → S2
Priority: P2 → --
Status: NEW → ASSIGNED
Priority: -- → P2

This is an emergency fix. We will think of something for the vCard parsing together with the calendar API for 114. Please do not hijack bugs.

Edit: Please ignore my request to not hijack bugs, which you certainly did not do. :-)

Whoops, why was this presented to me as a comment in my bug? Good lord. Sorry.

Because Neil is already assigned, I needed to make a quick decision, before he actually starts working on this. This comment

https://thunderbird.topicbox.com/groups/addons/T48d7c43269ed5f62-M20b713b33fe68dc6abba2a8f/contacts-api-broken-in-102-103

showed me, that we must reduce dependencies to the product as much as possible. I do not want to see add-ons break en masse, because we switch the lib we are using for generating the JSON, or that lib is changing its input/output format. I do not want to open up a new vector of failure.

As I outlined here:

https://webextension-api.thunderbird.net/en/latest/how-to/contacts.html#updating-the-vcard-property

it is only one line of code to get the JSON. Having the lib loaded gives access to the Component class, which makes handling the JSON even easier. What I will try to do instead (maybe with help of others) is to contribute to the upstream lib and add a Card class (similar to the Event class) to make vCard handling even less complicated. This will not only benefit Thunderbird, but all users of that lib, and may even increase its reach/usage. A broader use usually leads to more bugs being found, hardening the lib, which will benefit Thunderbird again.

I know I cannot make everybody happy, and in this case I will not make Ben happy. Using external libs is a common WebExtension approach and I will follow Firefox here and not expose a JSON format, which is delivered by an internal component, which might change in the future.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX

I'm just proposing to return JSON instead of a plain vcard text file. The property names and values are staying the same. The text<->JSON mapping is completely formal and would be stable. If ical.js were to change such a fundamental aspect, it would break all its users as well. I cannot see why the basic mapping would change. (And even in this unlikely case, we could still preserve the old mapping.)

The vCard text representation is very difficult to parse and practically impossible with a dedicated and complex third party library.

As I outlined here:
https://webextension-api.thunderbird.net/en/latest/how-to/contacts.html#updating-the-vcard-property
it is only one line of code to get the JSON.

This "one line" depends on a third party library, so it's actually 10000 (!) lines. We're not going to ship such a complex and large third party library with our addon, that's out of question for us.

I just causes unnecessary hassles to developers trying to use it. It also doesn't actually solve the stability problem. You'd get tons of copies of the same third party library, which then will exist in many different versions in various addons, because devs cannot update it every time there's an upstream release. Consequently, there'll be potentially security holes in various addons, given that libraries can have security holes as well, and addon authors have trouble to keep up. Therefore, each addon having its own copy of the library doesn't actually solve the stability problem and creates new problems in the entire eco system.

I'd really like to use WebExtension APIs, and only those. For the time being, we're stuck on the deprecated API.

Can we please talk about this, how we can solve this?

You need to log in before you can comment on or make changes to this bug.