391460 - maintain MRU list of possible applications

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Myk Melez [:myk] [@mykmelez]]

To make it easier for users to select an application to handle a given MIME type or protocol, we should keep an MRU list of recently used applications in the content handling datastore.  It's unclear whether we should keep type-specific (where type is either a MIME type or a protocol scheme), classification-specific (where a classification represents a group of types, like "event" or "image"), or an overall MRU list, so we'll need to figure that out.

The patch in bug 385740 means that possible handler applications are now represented by records in the datasource, so it should be possible to build upon that functionality to create lists of such applications.

We could do this in a variety of ways.  One possibility is to store the date a handler app was last used in the handler app record and then build the MRU list by retrieving an unordered list of handler apps and then sorting by date on the frontend.

Another option is to maintain a sorted list of handler apps in the datasource.  Per bug 385740, we are keeping a type-specific list of possible applications, but it isn't possible to sort that list in the RDF datasource, since the list is built via multiple assertions, and RDF datasources do not guarantee their order.

But maintaining sorted lists in the datasource is a suboptimal approach, since it ties us more to the current RDF implementation of the datastore.  If we were to switch to SQLite, we would almost certainly store records in unordered fashion in the database (since that's how databases store records) and sort them on the frontend (or in the query).

Comment 1

[cmtalbert]

If we need to write frontend sorting code while we are using an RDF backend, please file a follow-on bug (once the code is written) to remove that code and push the sorting down into the database query when we switch to a SQLite backend.  That's an important point that we don't want to consider when we design the SQLite Db to make that switch.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

It's not clear that we would push the sorting down into the database query when we switch to a SQLite backend.  At least initially, I think the goal would be to replace RDF with SQLite without having to make any frontend changes.  That's why we're building out nsIHandlerService as an API that encapsulates RDF-specific stuff so that the frontend never deals with it.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

This would be really nice, and I think was part of the design, but it doesn't block. Which isn't to say that we don't really want it :)

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

With a few exceptions, I'm mostly focused on MailCo-related hacking now.  Reassigning a bunch of bugs to default component owners.  I'm happy to help with brainstorming/advice as needed, however.  

Search for the string MAILMONKEY to delete any bugmail generated by this change.

Comment 5

[Rolf Leggewie]

I think bug 370380 presents the more generally desirable solution