New Account Types and data equivalency (was post TB 3.1 mailnews backend plans)

Andrew Sutherland asutherland at
Sun Jul 18 04:46:19 UTC 2010

  On 07/16/2010 02:40 PM, Kent James wrote:
> It applies much further than simply contacts. Items have many 
> different times, many different categories. Is a twitter # search 
> field like #moz10 more like a tag, or more like a folder? For that 
> matter, is a tag really any different than a folder?
> It would help to start if we would define the basic model of what we 
> are. For example: "Mailnews provides an aggregate view of data that 
> can be represented as individual items in a tree of categories (aka 
> folders), with metadata for each item that includes at least a text 
> summary (aka subject) and body (which could be the expansion of the 
> link in a twitter message)." If we could define the basic underlying 
> model of out items, and how they are extended and aggregated, we could 
> go a long way toward defining the data model that Gigabird needs to 
> succeed.

Raindrop has already done a lot of work in this area and it is 
definitely worth looking at what it has already accomplished when 
considering such things.  I believe the nutshell is that there is a 
(prioritized) concept of groups, and folders are one source of grouping 

The next revision of gloda will build on raindrop's data model efforts 
and change the gloda message invariant from the mailnews-ish "each 
conceptual message has exactly one location, is characterized by that 
location, and there may be more than one conceptual message with a 
message-id" to the raindrop and gmail-ish "there is only ever one 
conceptual message for a given message-id* and that message may exist in 
multiple locations with slightly different headers depending on 
transport routing".

In terms of gloda and back-end plans (as a general response to the 
thread), my current gloda plan is to use mailnews exclusively as a means 
of POP and IMAP protocol support with all new account types being added 
at a gloda level.  New account types defined at a mailnews level by 
those wishing to support Thunderbird 3.1 or otherwise operate at a 
sub-gloda level can be 'lofted' into gloda-space while maintaining 
custom semantics.  RSS's current mapping via gloda was not intentional 
and would be dropped in favor of a more usable gloda-level mapping.  
NNTP would continue to be ignored by gloda until either the mailnews 
nsIMsgDatabase performance characteristics improve or is reimplemented 
at a gloda level.


*We obviously want to handle malicious attempts to collide in the 
message-id space.  This will be eventually handled by using 
hashes/content equivalence to verify that message contents are identical 
and failing over to content hashes in event of such collisions.

More information about the tb-planning mailing list