Open Bug 1700779 Opened 2 years ago Updated 2 years ago

Merge nsIFolderListener into nsIMsgFolderListener

Categories

(MailNews Core :: General, task)

Tracking

(thunderbird_esr78 wontfix)

ASSIGNED
91 Branch
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: benc, Assigned: benc)

Details

(Keywords: leave-open)

Attachments

(1 file)

nsIMsgFolderListener has a comment suggesting that it should be merged with nsIFolderListener. Which seems likely, even just going by name :-)
So this bug is to track either merging the two, or updating that comment.

There are a couple of bugs related to the API presented by nsIMsgFolderListener which might have some bearing on a notional one-folder-listener-interface-to-rule-them-all design:

  • Bug 475506 - nsIMsgFolderListener could benefit from a msgsAdded batch notification and nsIMsgFolderNotificationService could be the batcher
  • Bug 1685484 - redesign nsIMsgFolderListener to use specific types rather than nsISupports

Some more notes:

nsIFolderListener:

  • can be registered either to individual folders, or globally, to the nsIMsgMailSession.
  • nsIFolderListener notifications generally originate inside the folder implementations, using the nsIMsgFolder.Notify* functions.

nsIMsgFolderListener:

  • defines listener callbacks for global registration with nsIMsgFolderNotificationService.
  • nsIMsgFolderNotificationService notifications are invoked from a bunch of places.
  • are registered along with a set of flags, so you just receive the notifications you're interested in, and the rest are ignored.
Assignee: nobody → benc
Status: NEW → ASSIGNED
Keywords: leave-open
Target Milestone: --- → 91 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/13acad3516f2
Add some comments to clarify nsIFolderListener/nsIMsgFolderListener distinctions. r=mkmelin

The JS side defines it's own listener class in DBViewWrapper.jsm: IDBViewWrapperListener.
DBViewWrapper catches various notifications and maps them onto IDBViewWrapperListener instead.

If the GUI needs to do this kind of thing, that's probably an indication that the XPCOM interfaces provided by the C++ side aren't quite what's needed. So the API set out by IDBViewWrapperListener should definitely be taken into account when designing any theoretical nsIFolderListener/nsIMsgFolderListener unification.

You need to log in before you can comment on or make changes to this bug.