On Thu, Apr 9, 2009 at 12:41 PM, Scott Violet <s...@chromium.org> wrote:
> There's one other bookmark notification you don't have, BookmarkNodeMoved.
A bookmark update when the parentID changes should cover this.
>
>
> Other interesting bookmark related methods:
> GetBookmarks(URL)
> GetMostRecentlyModifiedGroups
> GetMostRecentlyAddedEntries
Hmm, these could be query properties I suppose. This seems like a
nice-to-have.
>
>
> If you want to enable folks to replace the ntp, then shouldn't you
> provide a way to get the items displayed by the ntp? If someone is
> writing their own history sniffer or history page replacement that'll
> need to know when a new visit is added.
We do have events for that, I believe.
event onHistoryItemCreated(HistoryItem new)
>
>
> -Scott
>
> On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum <nickb...@chromium.org> wrote:
> > Hi all,
> >
> > I fleshed out a few more APIs. I've put them in separate documents since
> the
> > API pattern doc was getting a bit long. Below are some notes, feedback
> > appreciated.
> >
> > In particular, I'd love feedback from Scott on history and from Paul on
> > downloads.
> >
> > -Nick
> >
> > Bookmarks
> >
> > Do we want to distinguish removeBookmark from removeFolder, or is that
> > unnecessary?
> > Should changes to the contents of a folder trigger eventbookmarkupdated
> for
> > that folder? How about the folders above it?
> > In BookmarkItem, should fields that don't apply be null or simply not
> > present?
> > In BookmarksQuery, do the root and bookmarksBar booleans make sense?
> > How does returning the children recursively work with updates? Can you
> > update all these items at the same time?
> >
> > Downloads
> >
> > Should getDownloads take a DownloadsQuery object? The current downloads
> page
> > includes search.
> > What kind of events does clearAllDownloads trigger? do we need a separate
> > event for this? Do we even need this in the first place?
> > How should we deal with progress updates? It seems like overkill to
> trigger
> > an event for each change in percentage, but on the other hand extensions
> > should be able to track this.
> >
> > History
> >
> > I'm assuming HistoryItems are immutable, so there is no update.
> > The internal history structure is split between visits and urls. Visits
> > don't contain the actual url, so we have to fetch the url object either
> way.
> > I therefore merged the visit and url objects into one. Is this
> reasonable?
> > There are a number of stats (timeSpent, fromId, totalVisitCount,
> > totalTypedCount). Do we want to expose those for v1?
> >
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
