View source for 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 [http://mxr.mozilla.com/mozilla/source/mailnews/base 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 <code>nsMsgKey</code> or <code>nsIMsgHdr</code>), 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.

== Proposal Overview ==
The proposal mostly centers on the primary triad + folder + database at this stage and so far omits, for the most part, concrete interfaces.

=== Getting data ===
Primarily, the question of the overhaul centers on what is an account. I define an account to be a source (or amalgamation of sources) of messages. Note that a source is very loosely defined: a POP server is a source, as is an online mailing list archive, RSS feed, mbox file, maildir folder, or even a pseudo-source consisting of all messages where the subject contains "Thunderbird." Sources consist of three types: "server" sources, which are anything where you can subscribe to multiple "folders" all connected by a single "server"); pseudo-sources, which are sources that query other sources for messages (and include Local Folders since it seems the best place to me); and isolated sources, any other source which relies on one base URI to retrieve messages from, like a POP server or RSS feed.

An account may have multiple sources, but they must all be of the same type. How server-sources interact with accounts is still unclear.

An account has multiple folders, once again, of the same type. Each folder has an associated source (once again server sources are unclear), and has a parent and children. No more phantom root folder. Sources also have a pointer to their folder.

Databases, additionally, are per-account, so their referent link is from the account. Note that this idea was proposed before this proposal and has been in general accepted by the community as a good long-time goal.

=== Sending data ===
Identities present another conundrum. I personally don't like the name "identity," but my alternatives--persona, personality, character, interface, presentation--don't quite convey the idea correctly. Anyways, to distinguish the new version, I will call it a persona.

Personae control how a person sends information. Account types can register facets (another case of bad naming, I'm afraid), which are specific means to send a message. So mail provides your SMTP facet, news an NNTP facet, RSS a comment-posting facet. How facets and personae interact with accounts and sources is still unclear. Facets also probably provide too much complexity for too little benefit.

=== Displaying data ===
How the users sees accounts from the 3-window pane is not how the backend sees it. The overarching idea is this: I have some means to separate my sources of information: Mozilla, school, and personal categories. These categories cross account types: I receive mail for all three on a single POP account and mail for two of them on an IMAP account. Sometimes I'm interested in the same message in two different categories: I follow the WHATWG for some web development reasons, some personal reasons, and some Mozilla reasons. I therefore can't simply define three different profiles to represent these three different personae.

An account is not necessarily displayed in the folder pane, nor is it necessarily the same account at all. Whether or not accounts are displayed as such in the folder pane or merely as categorized folders is still unclear in my mind. Whatever is the case, an account provides some means to convert a folder to a viewable folder.

Also important is the separation of management. The account manager itself is completely UI-agnostic (i.e., no <code>nsIMsgWindow</code>'s please!). How protocol error notifications work is at present undefined. Where/how notifications, biff, and saved searches work are also undefined.

== Interfaces ==
Coming soon to a server near you!

== Comments/Questions/Concerns ==
Please post feedback here! Also, keep in mind that most uses of the word ''undefined'' or ''unclear'' indicate that I am ambivalent on the subject and can be easily persuaded one way the other. If you prefer to remain anonymous, you can also send email to [mailto:Pidgeot18+proposal@gmail.com my email address].