[webkit-dev] PageGroup and visited link coloring

[Brett Wilson]

Thanks for the response...

On Mon, Nov 10, 2008 at 12:56 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> I think it would be better to just always use a 64-bit hash with salting for
> all ports (assuming that is not a significant performance hit - I would
> expect it isn't). I say this because:

Okay, I will remove the ifdefs from my patch and make it all 64-bit.
What should I use to generate 64-bit hashes?


>> I'm thinking of just providing a new
>> PageGroupChromium.cpp which contains a different implementation that
>> proxies these calls to our glue layer to be sent to our multiprocess
>> database.
>>
>> However, I'm not sure what exactly the intent of PageGroup is. It's
>> clearly not intended that this be port-specific. Is there a cleaner
>> way to integrate our link database with the rest of WebKit?
>
> PageGroup is supposed to represent a set of Page objects (essentially top
> level Web content holders) which should be considered as together forming a
> "browser". Since WebKit is designed to be a public API framework and to be
> used for purposes other than a browser, it is possible for a browser to show
> some Web content views that are not part of the user's browsing. So it would
> put those in a separate PageGroup (however that is reflected in that
> platform's API). PageGroup takes care of those things that we judged to
> belong at this level of granularity, rather than global or per-Page.

Thanks for explaining this.

> I don't know what the right way to integrate Chromium's visited link
> checking would be. Do you incur IPC for every link checked? Does it cache on
> the client side? Does it use shared memory?

It uses a hash table in shared memory in such a way that it does not
require locking. Here are some links if you're interested. In our
terminology, a fingerprint is a 64-bit hash of a URL (generated with
MD5), and a hash is the position of that in the hash table. It uses
open addressing with linear probing.

Shared backend (handles hashing):
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/visitedlink_common.h
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/visitedlink_common.cc

Browser component (handles adding, resizing, regeneration from global history):
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/visitedlink_master.h
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/visitedlink_master.cc

Renderer component (just handles memory mapping):
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/visitedlink_slave.h
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/visitedlink_slave.cc

You can see this component is fairly complex, especially the master
which does a bunch of things asynchronously even in the browser
process. So I would prefer solutions to keep it as a standalone
component and plug WebKit into it. I thought I saw that Qt had a
similar constraint of an external visited link system, but I could be
wrong. This seems natural to me given that the history system is very
much external to WebKit, so that the visited link system (which is
kind of a part of history) would also be. Does that make sense?

Brett