After discussing with Rick potts about possibility of extending this to
Global History, following is what we came up with:
1) nsIWebBrowserHistoryEntry(described in my original posting as
nsIHistoryEntry) will be the super class for nsISHEntry in Session
History. nsISHEntry will implement getter/setter for LayoutHistoryState,
Postdata etc... nsIWebBrowserHistoryEntry will have getter for URI and
title.
2) GlobalHistory can have a similar nsIGlobalHistoryEntry interface
with methods:
GetLastVisitedDate()
GetNumberOfVisits()
Other methods specific to nsIGlobalHistory.....
nsIGlobalHistory can subclass from nsIWebBrowserHistoryEntry for
GetURI(), GetTitle().
3) With Global History we can provide an embeddor few options:
Option #1: The embeddor wants only link coloring and is not interested
in our implementation of Global History. To achieve this, the embeddor
should maintain his own list of previously visited urls and we will ask
the embeddor thro' the following method in nsIBrowserChrome, if it has
been previously visited and use the result to color the link.
boolean IsURIVisited(nsIURI * aURI) ;
nsWebShell::GetLinkState() should be modified like below to achieve this:
1) Call the above method in nsIWebBrowserChrome.
1a) If the call returned true, go ahead color the link
1b) else if the call returned false, don't color the link
1c) else if the method returned NS_NOT_IMPLEMENTED, goto step 2)
2) Check if there is an instance of global History in webshell
2a) If there is one, repeat steps 1a and 1b for the global history
instance
3) If there is no global history either, don't color the link
Option#2: The embeddor uses our implementation of global history which
will pull in RDF too.
Option #3: If the embeddor's need is to have just one instance of
browser, then the Session History is the global History, with no
persistence. The embeddor has to find his own ways to persist it. This
is a way to get Global History with out RDF.
Option #4: The embeddor doesn't need global History nor link coloring.
Radha Kulkarni wrote:
> Looking thro' and consolidating the notes at
> http://www.mozilla.org/projects/embedding/apiReviewNotes.html, here's
> what I have come up, as TBD for SH interfaces:
>
> 1) The embedding app needs to have a handle to a history object, which
> it can use to get information as well as perform operations on. For
> now, let me call this object nsIBrowserHistory and this will be a
> public interface. This is different from the existing
> nsISHistoryListener interface which is primarily a notification type
> of interface from the browser object to the embeddor.
>
> nsIBrowserHistory will have methods for the following operations.
> Please note that all this information is for the currently embedded
> browser object ie., session history only. No tie up with global
> history is provided here.
>
> a) Get the total number of entries in current browser window's history.
> b) Get the current position in the history list.
> c) Get and Set the maximum number of history entries that the browser
> object will hold. Currently this is accessible thro' Prefs UI.
> d) Get a enumerator object to go thro' all the entries in History. The
> object returned by the enumerator will be a public interface
> nsIHistoryEntry(described below).
> e) get access to a nsIHistoryEntry object at a particular index.
> f) Trim the History to 'N' entries.
> f) Setup or Remove listener for all History operations. The current
> nsISHistoryListener will be set/unset here.
>
> 2) nsISHistoryEntry: This is the public interface to get information
> about a particular history object. This interface will expose
>
> a) The url for the entry
> b) The title for the entry
> c) A flag that indicates if this entry is for a top level url or a
> subframe navigation.
>
> 3) Some of the items listed in 1) are currently provided by
> nsISHistory, which is not a public interface. I intend to refactor it
> so that the ones listed above are made public and everything else
> non-public. nsIWebNavigation will provide access to only the
> nsIBrowserHistory object, from which one can access a particular
> nsIHistoryEntry and get url, title etc... to build any menu.
>
> 4) There is a mention of refactoring the existing nsISHEntry so that
> url and title are accessible thro' a different interface. see,
> http://www.mozilla.org/projects/embedding/apiReviewNotes.html#nsISHistoryEntry
>
> My take on that is, though nsIHistoryEntry described above does that,
> I do not want to internally change nsISHEntry or its clients to use
> nsIHistoryEntry. This is because, nsISHEntry is used extensively and
> this would lead to lots of changes to the clients of nsISHEntry and
> internally in nsSHEntry.cpp. Instead, whenever a enumerator is called
> or a nsIBrowserHistory->GetEntryAtIndex(nsIHistoryEntry ** aResult) is
> called, we could create a nsIHistoryEntry object and get the required
> information from the corresponding nsISHEntry and return to the caller.
>
>
> Please provide your suggestions, Comments.
> Thanks,
> Radha
>
