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? > > Chrome has some notion of what the default place for new bookmarks is, such that when you click the star that's where it goes. Does it make sense to expose that to the API, such that someone can either use that fact (or change what that default is)? > > - > > 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. > > Should we expose some control over the downloads directory, e.g. give an extension the ability to create a subfolder in the downloads directory? An extension that wants to download a large number of images from various sites might want some way to organize them, for example. > > - > > 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? > > As a naïve reader (e.g. one who hasn't spent days pouring over these), what is fromID in History? Does that represent a navigation, e.g. fromID is the ID of the page you navigated from? What if it was something the user typed in the URL? Is there a constant to represent that? > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
