freaktechnik
commented
1 year ago Obviously the one component not mentioned is chat, which already tries to integrate into the mail account manager (which supports mail, feeds, nntp and chat accounts). The mail account manager uses prefs for storing its state, where the prefs are namespaced and contain the account ID. It also requires an "incoming server" in order for an account to exist (outgoing servers are optional).
Chat accounts only recently started to more faithfully respect the mail account manager and there is still a separate scheme happening within chat. There used to be an entirely independent account management system, and to some degree there still is, with its own account IDs and own pref namespace. See also https://searchfox.org/comm-central/rev/34306d86a28b61be0646388bba5a7b4bf8f8263b/chat/components/src/imAccounts.sys.mjs#980 and https://searchfox.org/comm-central/rev/34306d86a28b61be0646388bba5a7b4bf8f8263b/mail/components/im/IMIncomingServer.sys.mjs
A while ago I had talked about moving all of the chat account state to the mail account manager system, as to reduce duplication of logic and simplify chat code with Patrick, our chat module owner.
Problem
There is no clear definition of an "account" in Thunderbird, nor is there a central authoritative service for managing credentials and settings. As a result, the user experience of adding new calendars or address books under existing credentials is poor. Storage of account details largely occurs in preferences, which have no strong schema or links between entities sharing credentials. We store OAuth2 providers and scopes for accounts and do not provide a graceful means of updating them (as was necessary when we changed clients for Microsoft accounts). Determining the calendar to add email invitations to can result in some guesswork or unnecessary prompts to the user. For developers, it may not be clear where the responsibility lies for managing details.
Background
Firefox's concept of logins is fairly simple, as Firefox itself generally doesn't need to access an account, merely provide a quick means of allowing users to do so through a web interface. Thunderbird has to do a fair bit more work in this department, and these capabilities have grown organically over an extended period of time and sometimes through extensions. Without a clear architectural direction for accounts, functionality has been added where it was expedient to do so.
Potential Solution
Develop a concept of an account which has the ability to more closely match the accounts provided by services. As such, an "account" could be a single entity which covers an email address, a list of calendars, and one or more address books. Management of accounts could be centralized and allow for easy addition and removal of remote calendars and potentially removal of the separation between incoming and outgoing mail servers (while still allowing for manually specifying an outgoing mail server if needed; however, most users and most services probably don't regard these as separate). This could also allow us to centralize on a storage mechanism other than preferences in which we could store details about the various resources associated with the account.