Nice stuff. I think this question primarily applies to bookmarks, but how does the API deal with keeping states consistent? By the time a getBookmarks callback or an event reaches the listener (in a separate process), the bookmarks referred to may have changed or been removed already; even while the listener is processing the event itself. E.g something like updateBookmark would need to handle this at least minimally; if you update a bookmark that has been deleted, do we recreate it and encode that in a BookmarkInfo somehow, or should the API callback with a null BookmarkInfo (may be tough to do correctly at the right times)?
On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum <[email protected]> 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<http://dev.chromium.org/developers/design-documents/extensions/api-pattern/bookmarks-api> > > - 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<http://dev.chromium.org/developers/design-documents/extensions/api-pattern/downloads-api> > > - 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<http://dev.chromium.org/developers/design-documents/extensions/api-pattern/history-api> > > - 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
