468283 - gloda should expose action methods on its message and conversation objects

Status: NEW

(MailNews Core :: Database, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

for example:
- mark (message/conversation) as:
  - read/unread
  - starred/unstarred (flagged/not flagged)
  - junk/not junk
- delete (message/messages in conversation)
- tag/untag (message/conversation)

It has been proposed and agreed that using an nsMsgDBView to do the dirty work as an initial implementation is "not insane".

This is along the lines of our plan for unifying STEEL (bug 408370) with gloda.  We are not immediately moving towards using the existing STEEL implementations for two reasons:
1) The view does the dirty work of aggregating by folder.
2) I am concerned that there may be a lot of application-specific logic living in the view that is not in the STEEL logic, and I don't much fancy dealing with regressions right now.  For example, when marking a message as read, the view also nukes the 'new' attribute.

I think a beneficial implementation plan is to use the views for now, then implement by extracting the STEEL implementations (and using folder-partitioning logic.)  The key thing is that we then write a unit test that starts from equivalent messages and ensures that both mechanisms result in the same resulting message states.  (If we implement along the lines of my following points, this should be easy.)

From a conceptual perspective, we want to try and avoid assuming that every message is actually an nsIMsgDBHdr stored in an nsMsgDBFolder and that the nsMsgDBView is the correct implementation to perform mutations.

For example, in the "next gen" scenario where we would pull bugzilla information directly from bugzilla, we would want to index bugzilla comments as messages.  Strictly speaking there is no need for those comments to be stored as nsMsgDBHdrs.  This is not to say we won't go down that road, just that we shouldn't force ourselves to do so.

Comment 1

[David Ascher (:davida)]

We can't do anything real with the conversation views until this is done.  Boosting priority.

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

this is important for the exptoolbar extension, however it isn't lined up to block the thunderbird 3 release.