mozilla

Revision 128633 of Message Summary Database

  • Revision slug: Message_Summary_Database
  • Revision title: Message Summary Database
  • Revision id: 128633
  • Created:
  • Creator: DavidBienvenu
  • Is current revision? No
  • Comment /* Meta Information */

Revision Content

The Mail Summary Files (.msf) are used to store summary information about messages and threads in a folder, and some meta information about the folder.


nsIMsgDatabase

The main access point to the summary information is nsIMsgDatabase. nsIMsgFolder has a method to get the database for a folder.

nsIMsgDatabase is an abstraction on top of MDB, which is a set of db interfaces. The MDB interfaces are implemented in Mork. MDB is a schema-less db interface, so it's trivial to add new attributes without regenerating the db, and it's trivial for older code to read newer databases, because the code can ignore but maintain the attributes it doesn't know about. If we were to replace Mork, we could do it at the MDB level (unlikely, because implementing the MDB interface on top of a different DB would be very hard), the nsIMsgDatabase level (probably the easiest), or we could invent a whole new database interface and change all the code that uses the nsIMsgDatabase interface.

Message Headers

The message header object implements the nsIMsgDBHdr interface. This includes a set of per-message flags, the more commonly used headers, e.g., subject, sender, from, to, cc, date, etc) and a few other attributes, e.g., keywords. There are a set of generic property methods so that core code and extensions can set attributes on msg headers without changing nsIMsgHdr.idl.

Msg Threads

We store thread information persistently in the database and expose these object through the [nsIMsgThread interface. So the db knows which messages are in a thread, which message a message is in reply to, etc. This allows us to store watch/ignore information on a thread object, and avoids having to generate threading information whenever a folder is open. This has arguably been more trouble than it's been worth, especially when we've threaded incorrectly.

Meta Information

The nsIDBFolderInfo interface handles the folder meta data. This also supports generic properties. There is a method on nsIMsgDatabase to get the dbFolderInfo.

Revision Source

<p>The Mail Summary Files (.msf) are used to store summary information about messages and threads in a folder, and some meta information about the folder. 
</p><p><br>
</p>
<h3 name="nsIMsgDatabase"> nsIMsgDatabase </h3>
<p>The main access point to the summary information is <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/db/msgdb/public/nsIMsgDatabase.idl#122">nsIMsgDatabase</a>. nsIMsgFolder has a <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/base/public/nsIMsgFolder.idl#360">method</a> to get the database for a folder.
</p><p>nsIMsgDatabase is an abstraction on top of <a class="external" href="http://mxr.mozilla.org/mozilla/source/db/mdb/public/mdb.h#39">MDB</a>, which is a set of db interfaces. The MDB interfaces are implemented in Mork. MDB is a schema-less db interface, so it's trivial to add new attributes without regenerating the db, and it's trivial for older code to read newer databases, because the code can ignore but maintain the attributes it doesn't know about. If we were to replace Mork, we could do it at the MDB level (unlikely, because implementing the MDB interface on top of a different DB would be very hard), the nsIMsgDatabase level (probably the easiest), or we could invent a whole new database interface and change all the code that uses the nsIMsgDatabase interface.
</p>
<h3 name="Message_Headers"> Message Headers </h3>
<p>The message header object implements the <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/base/public/nsIMsgHdr.idl#51">nsIMsgDBHdr</a> interface. This includes a set of per-message <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/public/MailNewsTypes.h#94">flags</a>, the more commonly used headers, e.g., subject, sender, from, to, cc, date, etc) and a few other attributes, e.g., keywords. There are a set of generic <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/base/public/nsIMsgHdr.idl#55">property methods</a> so that core code and extensions can set attributes on msg headers without changing nsIMsgHdr.idl.
</p>
<h3 name="Msg_Threads"> Msg Threads </h3>
<p>We store thread information persistently in the database and expose these object through the [<a class="external" href="http://mxr.mozilla.org/seamonkey/source/mailnews/base/public/nsIMsgThread.idl#47">nsIMsgThread interface</a>. So the db knows which messages are in a thread, which message a message is in reply to, etc. This allows us to store watch/ignore information on a thread object, and avoids having to generate threading information whenever a folder is open. This has arguably been more trouble than it's been worth, especially when we've threaded incorrectly.
</p>
<h3 name="Meta_Information"> Meta Information </h3>
<p>The <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/db/msgdb/public/nsIDBFolderInfo.idl#42">nsIDBFolderInfo</a> interface handles the folder meta data. This also supports <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/db/msgdb/public/nsIDBFolderInfo.idl#72">generic properties</a>. There is a <a class="external" href="http://mxr.mozilla.org/mailnews/source/mailnews/db/msgdb/public/nsIMsgDatabase.idl#134">method</a> on nsIMsgDatabase to get the dbFolderInfo.
</p>
Revert to this revision