Alec Flett wrote:
> Judson Valeski wrote:
>
> > At the 1/18/01 meeting we discussed the following interfaces. Visit the
> > said URL and view the most recent notes for details.
>
> is the nsIGlobalHistory interface freezing? I don't see it on this list,
> yet it gets called from docshell, and hangs off of
> nsIDocShell::SetGlobalHistory()...
> since global history is probably our only reason for dragging in mork it
> seems like we'd want that to be replacable, and thus frozen...
Thus far we're not planning on freezing or publicizing global history. nsIDocShell
isn't
going public either, thus if that's your concern over nsIGlobalHistory (the fact that
docshell exposes it), don't sweat it.
> if this is the case, the existing interface needs to be split into two -
> one for embedders and one for neato browser features (i.e. stuff like
> RemovePage, GetLastPageVisited, and so forth)
hmm, maybe we need to be exposing a public cut of it. Why would an embedding app want
to
manipulate our global history (note, thus far, we haven't even been including it in
general embedding distributions; what are we losing by leaving it out?)? Maybe, to
affect our visited link colorization? Maybe they want to expose global history UI and
leverage our implementation of it (thus far we've been assuming embeddors would provide
their own global history; maybe that's not a valid assumption). This leads to the
inevitable UI question of "who's UI?" :-) If it's their UI, and they're just using us
for storage of the data, they'd probably need some enumeration methods to iterate over
all the entries.
What exactly does our global history impl do other than provide a list of urls visited
w/ pertinent visitation info?
> Since I brought this up, might I suggest:
> nsIGlobalHistory - the frozen, embedding one
> nsIBrowserGlobalHistory - a mozilla/navigator specific one?
Generally our iface breaking policy has been that nsIFoo get's split into nsIFoo
(public
version) and nsIFooInternal (the one *we* use).
Thanks for bringing it up.
Jud
