>> 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)
Will revisiting a URL still invoke this? I get in that case it's not a
create, rather an update. But ok, as long as the functionality is
there.
-Scott
>
>>
>> -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
-~----------~----~----~----~------~----~------~--~---
