Bug 17673 – Bring persistent history to WebCore

• Component: History
• Status: NEW

[Pierre-Luc Beaudoin]

The persistent history functionality should be brought to WebCore from WebKit.  This would allow all ports to share a common implementation.

It has been suggested to use SqLite as the engine, a dependency already existing for the IconDatabase.

[Pierre-Luc Beaudoin]

Created attachment 19532 [details]
Early preview

This is an early preview version.  It is a diff of my current workspace.  Recent changes (since the 21st feb) may have broken it but it compiles.

Main files of interest: HistoryDatabase*.* and what happens in FrameLoader.

This code is very inspired by IconDatabase, some of its behaviour have been kept in HistoryDatabase but may not have been necessary.  Please comment!

[Brady Eidson]

I will take a look at this if I get some spare time soon, or if it progresses closer to ToT/reviewable state.

Without even looking at code let me just say
A - This is a great thing to do that we have a radar for
B - There are a lot of things to get wrong.

Performance (main thread blocking) is concern #1, and thread safety is... also concern #1  :)

[Pierre-Luc Beaudoin]

Created attachment 19555 [details]
WebCore only version

I got time to test it against latest and apart from the title being never set, the url and time of visit are saved in the history.  The history pruning seems to works too.

This version should be easier to read.

[Brady Eidson]

I've started to look at this, specifically HistoryDatabase.  
I haven't focused on details yet, but I have a high level comment.

While it was logical to start with the icon database design, our understanding of "what works" for threaded WebCore code has evolved since then.  Primarily, I would recommend making the main thread loop be based on a MessageQueue instead.  Then construct a set of tasks that represent the different levels of granularity we need.  ie "Delete this one history item", "Update this one history item", "remove all history items older than this day", "remove all history items beyond the most recent N items", etc

Also, much of complexity of the IconDatabase design was me struggling with the forced notion of the per-icon retain count.  The IconDatabase had this very complex requirement of needing to keep around *only* the important icons the user agent cares about, but otherwise staying as pruned as possible.

The History Database will have no such limitation.  The pruning operations on History are much simpler - at a much higher granularity - than the Icon Database pruning.  Therefore the design has a lot of places it can be simplified.  I have a vague idea that the concept of all these different sets of items that need action taken on them can be reduced to using "the MessageQueue" for the history database.

I think this work has a great start but also has a ways to go.  Keep this bug updated as your patch progresses, and as I find more time this weekend, I'll attach much more detailed thoughts based on what we've learned in WebKit and how we'd like to make sure the move to WebCore makes it even better!  ;)

[Pierre-Luc Beaudoin]

Until more information is available, I won't push this further.  If someone wants to finish the job, assign this bug to you.

[Brady Eidson]

I think I'll be attacking this very soon.  I think it will make things easier by attacking it with a much more reserved plan than trying to get a cross platform database-based store in place in 1 big step.  

I think it makes more sense to put a "GlobalHistory" abstraction in place in WebCore that really is persistent-store agnostic, then worry about new ways to get the bits on and off disk later.

[Brady Eidson]

<rdar://problem/4880065>

[Adam Barth]

I think Chromium wants to be able to serialize history items for persistent storage as well.  I'm CC'ing Darin Fisher to he can contribute his two cents.

[Brady Eidson]

Does Chrome not use the FrameLoaderClient methods related to history that already exist...?  Right now, I don't intend to change the design that is in place at all, only move it from a WebKit to WebCore.

[Adam Barth]

> Does Chrome not use the FrameLoaderClient methods related to history that
> already exist...?

Darin is more qualified to answer this question than me (hopefully he'll chime in), but Chromium manages the back-forward list in the master browser process so that the back button can take the tab to another process, etc.  That means it wants to serialize history items to and from the rendering process.

> Right now, I don't intend to change the design that is in
> place at all, only move it from a WebKit to WebCore.

Ok.  I just wanted to loop Darin in case he could contribute to this discussion.