Personal History

How It Works

Architecture

In general, the PH plugin performs four functions:

• it monitors which web pages the user visits,
• it generates pages for the user to see (either external web pages or Personal History pages),
• it edits these pages to give the user a way to access his or her Personal History (e.g., by adding a toolbar that contains helpful links) and
• it edits external web pages by adding shortcuts when necessary.

MEG Model

The following diagram shows how the Personal History plugin processes a request using different types of Megs. These types include generators ("G"), monitors ("M"), and document editors ("DE"). The PH plugin does not use request editors. The diagram is symbolic in that the plugin actually contains many different Megs of the same type (e.g., many generators). The "G" in the diagram actually refers to the processing step involving generators. As we go through the scenarios, keep in mind that for the Personal History plugin, requests are HTTP requests and responses are HTTP responses (i.e., we're talking about web pages).

Scenario 1: Accessing an External Web Page

When the user clicks on a link to an external web page (i.e., not a WBI-created page), a request is created and sent to WBI. WBI recognizes the request and uses a generator to contact the external server and retrieve the page (the response). The response is then examined by a monitor, which collects information needed by the history plugin. A document editor edits the response by adding the toolbar (trail sign icon) and by possibly adding some shortcut links.

Scenario 2: Accessing the Auto Hotlist (Personal History) Page

When the user clicks on a link to Personal History, a request is created and sent to WBI. WBI recognizes the request and uses a generator to create a web page with a list of URLs and scores (the response). A document editor edits the response by adding the toolbar. Personal History pages are not monitored, and they do not contain shortcut links.

Implementation Details

• Monitoring pages: The PageIndexingMonitor gathers web page information each time a user accesses a web page, even if the user has previously visited that page. Some of the information collected includes the URL of the page, the date and time that it was accessed, and the content of the page. Each set of page information (one set per page access) is kept in a data structure of the class Step. The Personal History plugin stores these Step objects in a data structure of the class History.

  As a side note, there is no limit on how large the history and index objects can become. The PH plugin will always save the complete history and index to disk on shutdown and load them back in on startup. If these files get too large and you want to delete them, they are located in the data/history directory. The *.hst file is the history and the *.idx file is the index.

• Indexing page content: For each page access, the page's content is indexed so that it can be searched later. Indexing information is kept in a data structure of the class UpdatableIndex. The History class includes an UpdatableIndex object.

• HTML code for the Personal History pages: The history pages are created from a template using WBI's HtmlTemplateGenerator. The generator uses three files (inheader.txt, inbody.txt, and infooter.txt) to set the header, body, and footer of the pages. These files are retrieved as Java resources. The template includes a backlink to the most recent non-history web page visited and a form which allows the user to search the pages stored in the history.

• List of links on Personal History pages: The primary content of a history page is an ordered list of links. The way in which the list is created depends on whether the page is an Auto Hotlist page or a the result of a search.

  The Auto Hotlist page is reached by clicking on the Personal History link in the WBI toolbar. The links on this page are ordered according to how recently and how frequently the user has visited the various web pages. The score for each URL is calculated by using the page information, which was stored in the Steps in the History (specifically, the time and date that the page was accessed). The URLs are sorted according to their scores and are normalized on a scale of 1 to 100. Then the Auto Hotlist page is created, listing each URL (and its score) in order.

  The Searchable History page is reached by entering search terms into the form in the Auto Hotlist page. The links on this page are ordered according to how many times the web pages contain the search terms. This is determined by querying the information available in the history's index.

• Some key WBI classes that were used:

  com.ibm.wbi
  Proxy	used by UpdatableIndex
  com.ibm.wbi.protocol.http
  HttpResponse	used by PageIndexingMonitor
  com.ibm.wbi.protocol.http.beans
  AddPreambleEditor	used by AddShortcutsEditor
  HtmlTemplateGenerator	used by AutoHotlistGenerator and SearchableHistoryGenerator
  ResourceGenerator	used by HistoryFileGenerator
  FixContentTypeEditor	makes sure that content-type in http header matches actual content type of page
  FormHelper	helps extract query data from web forms
  PageMovedGenerator	used by SearchableHistoryGenerator
  com.ibm.wbi.protocol.http
  HttpEditor	extended by AddShortcutsEditor
  HttpGenerator	extended by AutoHotlistGenerator, HistoryFileGenerator, and SearchableHistoryGenerator
  HttpMonitor	extended by PageIndexingMonitor
  HttpPlugin	extended by PersonalHistoryPlugin
  DocumentInfo	used by AddShortcutsEditor, HistoryFileGenerator, PersonalHistoryPlugin, SearchableHistoryGenerator, and PageIndexingMonitor
  com.ibm.wbi.markuplanguage.html
  HtmlTokenizer	used by PageIndexingMonitor
  HtmlItem	used by PageIndexingMonitor
  HtmlTag	used by PageIndexingMonitor
  HtmlText	used by PageIndexingMonitor