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?
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.
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.
optional int[] ids: I don't understand what this is.
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.
Brett
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
