STATUS NOTE: this document needs updating. Some details may no longer be accurate.

The Mozilla History Project


guha
Judson Valeski
Robert Churchill

Goals

  1. Better (i.e., faster, leaner, easier to use) organizations and presentations of history.
  2. More intuitive auto-complete, possibly using history for pre-caching.

How it works today

mozilla.hst (or netscape.hst) is a DBM hashtable of the pages that have been visited in the last N (where N is typically equal to 9) days. Each entry has a title, date stamp, etc. The code that creates and maintains this hashtable is in ns/lib/libmisc/glhist.c
ns/modules/rdf/hist2rdf.c walks over this database and creates in-memory RDF structures corresponding to the clustering presented in the history section of NavCenter. Since the clustering is done when the browser comes up,
  1. We can't afford to do very sophisticated clustering.
  2. It wastes memory

How it should work

  1. We have a simple history update API that netlib uses to update the history database. The API is implemented on top of the RDF APIs.
  2. The on-disk representation should include the clustering which should be adaptive. The code for this can be taken from nlcstore.c. modules/rdf/src/hist2rdf and lib/libmisc/glhist.c should be replaced with this.
  3. glhist currently stores a lot more than it needs to --- images, interior frames, etc. We should avoid this. It would also be good to store trail information.
  4. glhist also currently supports auto-completion and this should be supported by the new representation.
  5. It should be possible for the history to be stored on a remote server (using some other on-disk representation --- this will be handled by the RDF abstraction layer).
  6. We should look into using trail information for pre-caching.