- Old tracking bug: bug 428378
- Initial Sync engine implementation: bug 675299
- Places changes: bug 674238
- Sync favicons for history and bookmarks
- Don't sync history favicons if only bookmark sync is enabled (viceversa not as problematic)
Important to sync up with the Places plan, which involves some schema alterations. mak is keen to reduce space overhead, which will likely see timestamps drop to int32, eliminate or render numeric MIME type values, and store large icons outside of the DB. It would also be nice to unify expiration timestamps and lastModified in the proposed favicon store.
API work should be done in mozIAsyncFavicons, not nsIFaviconService. It's experimental, which means we have more leeway to make changes, and of course it's asynchronous.
moz_places id guid url favicon_id -------> foreign key to moz_favicons.id ... moz_historyvisits id place_id ------> foreign key to moz_places.id visit_date ... moz_bookmarks id guid type fk ------> foreign key to moz_places.id ... moz_favicons id url data mime_type expiration guid (NEW) lastmodified (NEW? Integrate with expiration?)
bookmarks id (a.k.a. GUID) bmkUri ... faviconGUID (NEW) history id (a.k.a. GUID) histUri title visits faviconGUID (NEW) favicons (NEW) id (a.k.a. GUID) url data mime_type expiration?
faviconsengine with above data schema.
faviconGUIDproperty to bookmarks and history engines, it's synced as follows:
- Find favicon based on
a. it exists. Go to 3.
b. it doesn't exist. Go to 2.
- Create empty favicon entry with
- Refer to favicon id in the
More detailed plan
I propose a staged implementation, given dependencies on Places changes. Something a little like this:
- Extend bookmarks and history engines to track faviconURI. We do this instead of GUID as a trivial proof of concept, rather than waiting around.
- Implement favicon engine to sync favicons keyed by URI.
- Implement observers for nsINavHistoryObserver::onPageChanged/nsINavHistoryObserver::ATTRIBUTE_FAVICON to track bookmark/history changes on favicon alteration, and also poke the favicon tracker to ensure that changed favicons get synced up.
- Implement GUIDs for favicons, in line with the Places plan.
- Rejig favicon and other engines to use the GUID instead of the URI. This will, of course, be a breaking change (and we don't want to use URIs in production for privacy reasons), so this will be the first point at which this can be a user-facing feature.
- Reimplement bookmarks and favicons engines using async repository API.
- Switch to using mozIAsyncFavicons instead of nsIFaviconService.
- Is a blank entry in moz_favicons (cf. step 2 above) ok?
- How should we model the expiration (if at all)?
- How to access favicon data? Raw SQL r+w? Extend mozIAsyncHistory?
- mozIAsyncFavicons. This API is ours to chop up and extend, with appropriate judgment.
- How can we be notified when a new favicon is added or an existing one is changed?
- Observers. See above.
- How do we tie into or interact with Places' favicon expiration events?
- It would seem to make sense to sync favicons before bookmarks, so as to have favicons present in the DB before they are linked to their bookmark record. We should also take care to keep toolbar/menu icons very much in the working set: synced first, and generally given priority. UX über alles!
- I disagree with that. It would be more useful to see people's bookmark toolbar/menu etc. populated with entries and then add the favicons quickly thereafter... Favicons could probably take considerably more time to sync than bookmarks... But as you say, that's something for UX to decide. --philikon
- Can this scheme easily be extended to work for things like site thumbnails?