On Thu, Apr 9, 2009 at 12:01 AM, Brett Wilson <[email protected]> wrote:
> 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 > > > > 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? > > I would recommend doing as little as possible for history. I worked on > a fancy querying system for Firefox history which has not really been > used for great effect. We should add features as necessary for things > we want to enable. > > The visits and URLs are split out for space reasons. The URL record > has a couple of strings and a bunch of numbers, and the results will > contain many copies of the URL (for example, imagine the URL, favicon > URL, and title (many common titles are actually quite long) for your > homepage being duplicated hundreds of times for a longish history > query. If the results are limited to 100, space doesn't matter, but > splitting them makes some things easier. Say I want to display only > URLs, it keeps me from having to go through every one and uniquing > them. So I guess either way is OK with me. Yeah, that's true. On the other hand, keeping them together means that you don't have to fetch all the urls when displaying visits. I say let's try it as is for now. > > > I like the idea of limiting the result set to 100. It's too easy to > shoot yourself in the foot. I also think you should not be able to do > a query over too much time. For full text search results, we've spent > a lot of time doing these in chunks. Doing a search for something over > all time can easily churn through hundreds of megabytes of data. Our > history code does it incrementally by month, so I think this would be > a good thing to "encourage" in the API design that you can't do a > query over more than one month. > > int timeSpent: we don't know the time you spent on the page, so remove > this. Oops, I misinterpreted the visitTime field in the schema. Got it now :) > > optional int[] ids: I don't understand what this is. An explicit list of ids to return. > > > int totalPages: I assume you mean the total number of result sets of > 100? This number is not possible for us to compute for queries with > full text searches, and is merely very impractical for other ones. > > optional int page: We can not efficiently do full text queries by > count "give me the 30-40th results" since it must find every match for > the text before it can do any such computation. > > Given my suggestion to keep it simple, I think the query API should > more closely reflect the current C++ API, which was carefully designed > to be efficient. Instead of asking for individual pages, you do a > query over a time range for "up to 100 results". If you want more > results, you start at the last date and continue to go back in time, > getting more results. This requires some more work by extension > authors, but not a lot more. If we see there are many applications > with certain needs, we should design better APIs for those specific > needs. Ok, that makes sense to me. Given that our history code queries by month, should we limit the API to return max(1 month, 100 entries)? or should we just stick to 100 entries to keep it simple? > > > Brett > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
