Nick, thanks for doing this. Overall, I think this looks great, and it fits with the way I imagined these would work. I have answers to your questions inline, plus some other nits below.
Some of these things I just went ahead and made the changes. We need to somehow rationalize all these docs we have. Some of them are historical and can probably be cut down. Like the majority of the pattern doc. On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum <[email protected]> wrote: > Do we want to distinguish removeBookmark from removeFolder, or is that > unnecessary? I like it as-is. > Should changes to the contents of a folder trigger eventbookmarkupdated for > that folder? How about the folders above it? This is a meta question for the entire system. My current thinking is that changes you make should not fire events back at you. That just seems annoying. I think there should also be defined behavior in cases where something you do will obviously affect other nodes, and that those changes shouldn't be fired at you either. For example, moving a bookmark item within the folder obviously affects some of the other nodes. We should have a defined behavior for what happens when you do this, and we shouldn't fire events back at you for any of those changes. > In BookmarkItem, should fields that don't apply be null or simply not > present? Another meta-question. I think not present ("undefined" in JS lingo). This fits with what developers are supposed to do when they send objects _into_ the API. > 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? I took away "root". I think it fits better with the other APIs to have ids default to "root". I think we might want to extend all the update APIs and remove APIs to accept multiple objects as arguments. But I'd like to wait on that to see if we find a use case for it. Other stuff * I camel cased the events (in all the APIs) :-) * I added letters to the left of all the properties in each struct of each API. There is 'r', 'w', and 'c', which refer to read, write, and create. This determines whether it is valid to include this property in each of these scenarios. So for example, it doesn't make sense to create a bookmark with a predefined API. There will be other validation we have to do on top of this. Like it doesn't make sense to change a bookmark to a folder, but this handles a good percentage. > Downloads > > Should getDownloads take a DownloadsQuery object? The current downloads page > includes search. Yes. All the get/create/update/remove APIs should work the same way. You should be able to guess how to get a download by ID because you already know how to get a history item by ID. Yes to including text. I made these changes to the doc. > What kind of events does clearAllDownloads trigger? do we need a separate > event for this? Do we even need this in the first place? See previous point about events. I'm <meh> about the need for clearAllDownloads(). Take it or leave it. > 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. Why is it overkill? Other stuff: * I added two booleans: showInShelf and showInDownloadUI. > 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? I think it would be useful to spec v2 things out to make sure we're thinking ahead. I went ahead and added APIs to get the additional stats. I renamed getHistoryItems to getHistory and the same for create and remove. I like the phrase that this forms "create history", "remove history" :). I modified the signature of the getHistory callback to make it more consistent with the other APIs. Instead of returning the number of pages, I think it is more useful to return the total number of items. Also I don't think we need to return the page number since the caller already has that. - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
