Replacing Mork with Sqlite (was: post TB 3.1 mailnews backend plans)

Kent James kent at caspia.com
Fri Jul 16 19:15:06 UTC 2010


  Several issues here.

1.    Mork-specific database features

In my iGdb experimental SQLite-based nsIMsgDBHdr from a couple of years 
ago (https://bugzilla.mozilla.org/attachment.cgi?id=348353 on bug 
11050), one of the difficult issues was various unusual ways that 
mailnews code took advantage of mork-specific features, particular in 
threading. Those don't map well to SQL. It would be useful to identify 
those, and redesign the database use to remove mork-specific features, 
so that a common interface could support both SQL and mork backends as 
well.

2.    Async versus sync:

After discussion with asuth on my blog and in person, I've redesigned by 
EWS persistent storage to use two separate files, one for sync use of 
fast retrieval of the datablob from an indexed key, and another that 
does async queries that duplicates fields that need queries. It is not 
clear if this separation will be needed in the version of SQLite that 
will ship with Mozilla 2.0  But this design greatly simplifies the issue 
of conversion. It would be much easier to convert the few uses of large 
queries in the backend database (such as "give me a list of all messages 
with the NEW process flag set") and just leave the vast majority of 
accesses (like let subject = hdr.subject) still be sync.

3.    Direct conversion from native formats.

In my design, I maintain a clean separation of a "native" version of my 
Exchange data, from the mailnews/Skink backend versions. But that means 
that I have to maintain the same data in two independent databases. I 
believe strongly in the value of keeping the various layers as separate 
as possible, particularly since that means that the same EWS code might 
be usable in a Firefox or Gigabird extension. It would be great if the 
database interfaces were robust enough to allow me to simply supply 
conversion routines, so that hdr.subject could talk to my database 
directly, instead of forcing me to copy everything to your database. I 
think this is a general concept that could be applied to other data 
formats as well.



More information about the tb-planning mailing list