1128595 - Sqlite db for favicons

Status: RESOLVED FIXED

(Firefox for iOS :: Favicons, defect)

Description

[Wesley Johnston (:wesj)]

We need to move the current favicons code over to use sqlite.

Comment 1

[Wesley Johnston (:wesj)]

Attachment: Pull request

Whoever can get to this first. From the PR:

This gets favicons using a JS shim. They're then stored locally (on disk), and the url -> site mapping is stored in a local database. The disk cache is just stored as a hash of the filename.fileExtension. That means if we can lookup the url in the database, we can load the local file. I also added a join on the history table for the history API to do that lookup simultaneously.

The schema for the favicons table is
url -> String
date -> Double // date this was saved. I need to update this as you browse
width -> Int
height -> Int
type -> Int // What type of tag this came from. I'm storing things like apple-touch-icon right now, and wanted to make sure we could disambiguate those

That has speed tradeoffs I'm sure. This doesn't handle loading them asynchronously into the table yet.

Comment 2

[Richard Newman [:rnewman]]

This is an area where I have no objections to using CoreData, btw.

Comment 3

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

(In reply to Richard Newman [:rnewman] from comment #2)
> This is an area where I have no objections to using CoreData, btw.

That is a bit odd. Then we have to invest in two different storage layers. Why not use what we have?

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Comment on attachment 8558006 [details] [review]
Pull request

I did a review but most of my comments are Swift style related. I'm having a hard time seeing the big picture of the storage code so I did not comment much on it. (That is not a code problem, but simply that I have not invested much time in understanding the Storage code)

I'm ok with a +r but I think :rnewman should probably take a deeper look at at the storage details.

Comment 5

[Richard Newman [:rnewman]]

(In reply to Stefan Arentz [:st3fan] from comment #3)

> That is a bit odd. Then we have to invest in two different storage layers.
> Why not use what we have?

Just expressing no objection, not making a recommendation or request!

There's no pressing need for Sync to dig its fingers into favicons, so I just wanted to open the door to whatever is easiest for frontend code here.

Comment 6

[Wesley Johnston (:wesj)]

Landed.