Thanks for the response... On Mon, Nov 10, 2008 at 12:56 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
