Firefox/Projects/Places async expiration

Summary

Decouple expiration from history service and make it completely async and adaptive to user habits (expire harder for heavy history users, less for casual users).

Current Status

Getting started with design.

Next Steps

• Take decision on position and form of the code (service? component? module?)
• Evaluate interactions with other components/services
• Code it
• Test it

Related Bugs

bug 520165

Team

• Project Leader: mak
• Reviewer: mano
• Consultant: Places Team

Designs

Separate expiration from history service, make it async in background.

Goals/Use Cases

• Work in background: no ui-locking
• Avoid idle if possible: mobiles could hardly hit idle, it's unclear how often a mobile dev can use idle. In any case we should not loop in idle to avoid killing batteries (mobile and laptop)
• simplify bloat history code
• simplify and add coherency to expiration code
• ensure notifications consistency

Non Goals

• over engineer things

Thoughts to be parsed

• Should we hook into PlacesDBFlush? actually expiration code hooks into it to run just before a flush, but this makes the code more complex and less readable/self-contained... If we are going to increase number of async expiration tasks and we plan to remove temp tables, could make sense to strip out this code path from the flusher.

• Actually we have a bunch of strange notifications, we have onDeleteURI but also onPageExpired. On the other side we don't have onDeleteVisit, why?

• During batches often we don't notify, this was done for perf purposes, but really should be observers that ignore notifications during batches, not us that don't fire them. This makes hard for extensions and third party users to follow what happens. We should ensure to always notify changes (this does not happen on clearHistory since it's pretty clear that all history will be cleared, even if at that point you can't know if an uri has been removed or not, it could have been a bookmark. Should we notify onDeleteURI instead?).

• If possible we should completely avoid or highly reduce expiration at shutdown. We must expire in background, adapting to the situation. Thus making shutdown expiration useless.

• Idle can be a problem, if from one side it's pretty cool to be able to expire large bunches of informations on idle, on the other side we should consider some problematic. First user could be idle because watching a video, we should not hit him with large bunch of disk I/O. Also idle is a particular condition on mobile devices, could be some user will just open the browser, visit a page, and close the browser, in these situations idle won't ever be hit, so we should not rely to much on idle. Luckily in those situations the size of data to be managed is smaller.

• Expiration is not needed at startup, so we should try to init it later, but being part of toolkit we can't just use browser delayed startup. Maybe just add it as an history observer category, but start expiring later, on a timer.