202
edits
Changes
→Approach
== Approach ==
=== History view ===
Coalescing redirefcts will be an optional portion of history queries, so callers can get the raw visit data if desired.
When the history system gives query results by visit, we will hide the sources of redirects and only show destinations. For all visits X that result in redirects to Y, we will remove X and add Y (if Y isn't already in the result set). Then repeat this optimization until there are no redirected visits (to handle multiple redirect hops)
This handles many cases: multiple redirected destinations from X, mutiple redirect sources from Y. It also means that if you do a query and it matches the source, you'll get the destionation even if the query doesn't match the destination. There are some strange results, however:
* In rare cases, the user will be manually looking for a given host name or other attribute that occurs in the source but not the destination. This attribute may not appear in the result set.
* If the query is "all pages on host Z" and one of those results is a rediirect to another host, it will be surprising to see another host in the result set.
When queries for visited web pages are done, it is less clear what to do. Since redirects can change temporally, it may not be clear which redirect to use, and which pages deserve to be in the result. The ideal solution depends on what the expected use of non-visit-based history queries are, which is not yet clear. One solution is to not coalesce redirects at all. The other solution is, for a page X, if there is some (or perhaps, the most recent visit) that is a redirect to Y, substitute X with Y. This will be wrong if X's redirect changes, but this should handle most cases.
