User:Jcranmer/AMProposal
This is my mailnews account manager proposal. I have generated this proposal as an amalgamation of my experience working with news code and my experience attempting to create a new account type in JavaScript from an extension (not an easy task). Please note that there is absolutely no chance of this being implemented before the release of Thunderbird 3, nor even of being fully fleshed out before then.
What it is
Today, the account manager (a term I use both to refer to the actual manager portion and the entire account system as well) is a complex hydra of interacting interfaces, many of which are related but in nontrivial ways. Most code resides in mailnews/base, although the database code lives elsewhere. The primary interaction is the identity, server, and account triad, all three of which are more or less managed by the account manager itself.
Several more interfaces come into play in the system. Servers contain a folder which recursively contain folders. Folders contain databases (of keys and key information, represented by either nsMsgKey or nsIMsgHdr), and can translate keys into URIs to be queried from the server. There is additionally the folder cache to aid with some default folder statistics, as well as other management services for other portions of code. Finally, the message window is heavily passed between components and acts as UI glue, along with the database view.
Goals of new account manager
Before proposing a new manager, I want to list the principles that guide my ideas.
First and foremost is the UI. For simple users, it should just work. For power users, it should be flexible and sensible. The backend reorganization should make the UI portions easy to write.
Second is extensions. Providing a new account type from an extension should be easy.
Finally comes the internal use. The account manager must be useful internally and allow certain interactions to come naturally. For example, cross-account interactions and account-agnostic interactions must be simple from an API perspective.
Also specific is the type of accounts it can handle. Right now, the account manager balks at accounts different from a "mailnews" account (i.e., POP, IMAP, NNTP). The new account manager must be flexible enough to handle RSS and IM accounts comfortably, and should be flexible enough to allow even off-the-wall, unprecedented innovations to fit comfortably as well.