CloudServices/Sync/FxSync/FaviconSync: Difference between revisions
< CloudServices | Sync | FxSync
Jump to navigation
Jump to search
No edit summary |
(Coordination notes.) |
||
Line 5: | Line 5: | ||
* Sync favicons for history and bookmarks | * Sync favicons for history and bookmarks | ||
* Don't sync history favicons if only bookmark sync is enabled (viceversa not as problematic) | * Don't sync history favicons if only bookmark sync is enabled (viceversa not as problematic) | ||
= Coordination = | |||
Important to sync up with the [https://wiki.mozilla.org/Places:Plan 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. | |||
= Proposal = | = Proposal = | ||
Line 37: | Line 43: | ||
expiration | expiration | ||
guid (NEW) | guid (NEW) | ||
lastmodified (NEW?) | lastmodified (NEW? Integrate with expiration?) | ||
</pre> | </pre> | ||
Line 78: | Line 84: | ||
*How should we model the expiration (if at all)? | *How should we model the expiration (if at all)? | ||
*How to access favicon data? Raw SQL r+w? Extend mozIAsyncHistory? | *How to access favicon data? Raw SQL r+w? Extend mozIAsyncHistory? | ||
** mozIAsyncFavicons. | |||
*How can we be notified when a new favicon is added or an existing one is changed? | *How can we be notified when a new favicon is added or an existing one is changed? |
Revision as of 20:01, 28 July 2011
See also bug 428378
Goals
- Sync favicons for history and bookmarks
- Don't sync history favicons if only bookmark sync is enabled (viceversa not as problematic)
Coordination
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.
Proposal
Firefox (places.sqlite)
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?)
Sync
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?
Implementation
- Implement
favicons
engine with above data schema. - Add
faviconGUID
property to bookmarks and history engines, it's synced as follows:
- Find favicon based on
faviconGUID
a. it exists. Go to 3.
b. it doesn't exist. Go to 2. - Create empty favicon entry with
id
andguid
. - Refer to favicon id in the
moz_places
entry.
Questions
- 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.
- How can we be notified when a new favicon is added or an existing one is changed?