support CardBook addon !

[CardBook]

CardBook is a new (CardDAV) address book.... would be great to support it...

[protz]

There is a plugin mechanism and there used to be a sample plugin in the tree... could you take inspiration from the Enigmail plugin and try to write a similar interfacing mechanism for CardDAV? Alternatively, I'd take a pull request if the patch is not too invasive... Thanks!

[CardBook]

I've tried to use conversation, but haven't found where it deals with contacts,,,

[protz]

In the source tree, there's modules/contact.js

…

On 6/12/17 3:11 AM, CardBook wrote: I've tried to use conversation, but haven't found where it deals with contacts,,, — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1193 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANGs8EMc6CZ1ZtC8CsiNf5H6iRHkdwZks5sDQ7hgaJpZM4Ne0sO>.

[rootandy]

Any updates here?

[CardBook]

even without CardBook, how do you add|edit|delete a contact into the address book from a conversation ?

[rootandy]

hover the name, wait a few seconds, a window appears, press the plus icon and then the contacts icon - result: a window with the name appears. But my primary concern would be replacing this circular image by a contact image from CardBook.

[ovari]

https://gitlab.com/CardBook/CardBook/issues/616

[ovari]

Would code from #826 help?

[bepolymathe]

Any news about that ?

[Standard8]

Having just looked at this due to the report in #1673, there's a few issues here:

Cardbook is not providing address book integration support - it does not act like a traditional Thunderbird address support, for example, if you create a Cardbook address book and then look in Thunderbird's address book windows, then the Cardbook will not show up.

This will prevent Conversations from finding contacts within Cardbooks - as Conversations is using the standard Thunderbird APIs. The functionality that is broken as a result is:

• not showing display names of contacts (or only display names).
• not being able to add/edit cardbook contacts from the contact pop-ups

Whilst I am keen to support other extensions where possible, the non-standard way of doing things makes it difficult here, and with the move to more standard WebExtensions API, I do not want to implement code specific to other add-ons.

With respect to Conversations finding contacts from Cardbooks: This could now be implemented in Cardbook via a new browser.addressBooks.provider.onSearchRequest API that has just been added in Thunderbird 91. This would provide at least some read-only functionality. There have also been discussions about making it possible to read and write - which would require more work, but I believe the Thunderbird address book architecture is now ready for it to happen with the recent changes.

With respect to add/edit cardbook contacts from Conversations UI: The way Cardbooks currently does this is via a separate context menu item. As Conversations doesn't really support the context menu item there, it doesn't quite fit. If Cardbook integrated with Thunderbird's address book directly, then this functionality would be obtained virtually for free.

The only thing I think I would be prepared to do in Conversations is if Thunderbird added a specific API for adding functions for contacts in the message header, whereby Cardbook could register something which would then work in standard Thunderbird, and Conversations could also implement - however I think this would still be a work-around for the lack of integration.

[CardBook]

Hi Mark

what do you need to make it work ?

Philippe

[Standard8]

@CardBook I think my previous comment says most of it - if Cardbooks integrated more with the address book system in Thunderbird, then this would be virtually no work for Conversations (or other add-ons) to do. As I wrote, you might be able to start using some of the new functionality in TB 91.

[CardBook]

CardBook offers a new address book so it can't be better integrated... I can also say the same thing : Thunderbird Conversations does also not use the standard way for using Thunderbird email-address node... if Thunderbird Conversations integrated more the standard email-address node, this would virtually be OK...

so do you need I expose some functions or whatever (like I do for others add-ons) ?

[Standard8]

CardBook offers a new address book so it can't be better integrated... I can also say the same thing : Thunderbird Conversations does also not use the standard way for using Thunderbird email-address node... if Thunderbird Conversations integrated more the standard email-address node, this would virtually be OK...

Conversations implements a different display, but it is using more and more of the core WebExtensions APIs (e.g. browser.contact.*).

My ideal goal for Conversations would be for it to operate 100% as a WebExtension with all the WebExtension APIs supported. It is going to take a while to get all the way there though.

so do you need I expose some functions or whatever (like I do for others add-ons) ?

I am willing to attempt to make Conversations work with WebExtensions APIs so that other add-ons can create buttons and things and they'll be supported (e.g. #1665 as one example). However at this time I am not willing to support special add-on specific changes - Conversations is quite complex and I'm trying to simplify it where possible. Supporting only the standard WebExtension APIs makes that much simpler.

I think as I mentioned above, implementing browser.addressBooks.provider.onSearchRequest in TB 91 would be a good start as at least other add-ons could use the same core contact data when displaying emails. It would probably also simplify your code a bit as you wouldn't need the autocomplete handling for the compose window, as that API would do it for you.

Longer term, I think it depends on what your goals are for the CardBook add-on. If you want to keep it as a completely separate address book implementation, then I think you need to work to find ways to use or extend the WebExtension APIs, and re-implement those - otherwise you're are likely to keep hitting these issues as new add-ons get released which are less likely to use experiments. I realise it is a lot of work, but generally I think it would be a good thing if all of Thunderbird's add-ons were able to support the same set of WebExtension APIs.

One other thought I've just had is that Thunderbird's address book has just been rewritten into JavaScript and now uses sqlite, so now might be a good time to discuss about changes to extend it to help with CardBook support - e.g. why is CardBook a completely separate implementation? If there's not enough support of fields etc then they may now be easier to add.

[biva]

Hello @Standard8 and @CardBook I understand that making both addons work together is not the easiest, technically. For your information @Standard8 , a lot of people pushed Thunderbird to use CardBook as the default address book (https://bugzilla.mozilla.org/show_bug.cgi?id=1372580) but for some reason the TB team has chosen another direction.

I know that CardBook developer is really reactive and does his best to solve issues and improve the compatibility. As implementing 100% of WebExtension APIs is a huge work for everybody, don't you think @Standard8 that there could be a middle way, with probably not too much added complexity (I might be wrong here, sorry if I am), so that Conversations is compatible with CardBook? I understand your fear that if any addon needs a specific change, then it's impossible for Conversations. But CardBook is one of the most used extension, and for a core feature of an email client (address book). It is even one of the 9 "featured" extension, like Conversations. Maybe it would worth considering it?

In any case, thank you so much for your work, Conversations is fantastic :)

[Standard8]

Closing this out. As stated above, I think Cardbook should implement the browser.addressBooks.provider.onSearchRequest API, which would then allow other add-ons to find the contacts using the standard APIs.

Whilst I realise there may be extra fields and other items I don't see that Conversations needs to access those at this time, and Conversations is primarily only concerned with the names of contacts and photos.