494380 - [meta] Better notifications for Places

Status: RESOLVED INCOMPLETE

(Toolkit :: Places, defect)

Description

[Marco Bonardo [:mak]]

There is a bunch of information that we miss when we fire notifications, this causes the observer to discover informations by itself, that is expensive since we do already know those. Some example:

ItemAdded should tell me which kind of item has been added, and the dateAdded time that has been associated to the item

ItemChanged should tell me item type, both old and new value, and the lastModified time that has been associated to the item

ItemRemoved should tell me item type (same for onBeforeItemRemoved)

basically we should look at what we most likely have available when we fire a notification, and pass that data, so who receive the notification does not have to query the db again to discover why it has received it.

Comment 1

[Drew Willcoxon :adw (Away July 17–July 24)]

Is this bug for nsINavHistoryObservers, nsINavBookmarkObservers, nsINavHistoryResultViewers, or all of the above?  Dependent bug 497387 appears to refer to nsINavHistoryResultViewers only.  (Bug 498032 needs a better nsINavBookmarkObserver.onItemChanged or a nsINavBookmarkObserver.onBeforeItemChanged, and I'm trying to figure out if this bug blocks or solves that.)

Comment 2

[Marco Bonardo [:mak]]

i want to file a new bug about adding item type, and make this depend on that. We can use this bug to add ideas to implement to make notifications better.

Comment 3

[Marco Bonardo [:mak]]

changing into a meta bug, Mano is working on bug 498130 that should implement partially ideas expressed here and on our plan page.

Comment 4

[Marco Bonardo [:mak]]

superseded by bug 1340498