202
edits
Changes
→Link coloring
To solve this problem, URLs will be loaded into an in-memory database when the application starts (or, perhaps, the first time they are required). These links can be sorted so they can be accessed very quickly, and rquire no OS calls or file locks. This list will only contain URLs, and none of the extra information such as visit dates, visit counts, and titles.
Because this data will reside in memory, it is important to not take too much space. If we suceed in the goal of allowing users to keep large amounts of history, size could be significant. We will therefore want to limit the number of URLs that we bring into memory, either allowing, for example, the past 10K URLs, or the past 30 days of visits.
A two-level approach may improve perceived size. Most URLs in the table are ads and random images from web sites that the user will never see a link to, and probably wouldn't even care about if they did. Then there are the top-level pages (with hidden=false) that are the top-level URLs that the user actually visited. They are much more likely to care about these top-level links. To save space and speed things up, we could keep the past X URLs in memory, plus the previous Y top-level URLs. It is unlikely that users will even notice that most of their history links are not being used for link coloring.
==== Database size ====
I just imported my Mork history database file into the equivalent sqlite format. The sqlite file was 10x smaller than the original Mork file.
