>Firefox Bookmarks & History Query API (re)Design

2009/11/07 — 3 Comments

>With the Firefox UI/UX team starting to crank out design ideas for “Places” ( a Mozilla internal name for bookmarks and history) in Firefox 3.7 and 4.0, it’s high time the Places team revamped the query API.

Alex Faaborg has posted some initial UI concepts here: http://blog.mozilla.com/faaborg/2009/10/13/browsing-your-personal-web/

I have started to think about how to make an elegant API to do the heavy lifting of querying the Places database for bookmarks, history and related hierarchies. The current Places query API is not simple to use, and we want this to be simple and easily extensible by extension authors, as well as a drop in api for Jetpack.

The bug for this work is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522572

One of our non-goals is to make a snap in replacement for the current API. We get to focus on the new features, like “browsing” your bookmarks and history in content-space, as well as accessing bookmarks and history via the “awesomebar”.

I have posted the beginning stages of this work to the wiki, here, the Firefox “project page” is here. We are in a stage of thinking about and sketching what this simple, elegant API might look like, and we would love to get feedback and ideas from our colleagues and the Mozilla community. The Places 3.7 meta bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=523519

Advertisements

3 responses to >Firefox Bookmarks & History Query API (re)Design

  1. 

    >It would be nice if keyword can be added as a facet for the bottom example as well.It is unclear to me what "param" means. Is that a full text search of title + url? How does it deal with multiple words, and how does _that_ deal with looking for an exact phrase? The same applies to "exclude".Love the fact that everything is async – it'll be harder to use from non-main-thread-C++, but that's a non-goal (and leads too easily to people doing it from the main thread incorrectly).

  2. 

    >I'll note the 'keyword as facet', great idea."param" is a phrase, a part of a title or a url, I also wonder if we should start pulling in all meta-tags like keywords and description. I think we will come up with a better name for "param", it is kind of opaque.We pretty much have to go async everywhere, its the only way to keep performance from regressing and to keep the UI from locking:)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s