[webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Brady Eidson]

> On Jun 15, 2017, at 10:54 PM, Carlos Garcia Campos <cgarcia at igalia.com> wrote:
> 
> El jue, 15-06-2017 a las 17:11 -0700, Brady Eidson escribió:
>> Hi all,
>> 
>> The IconDatabase in WebCore is the source of crashes, spins, and
>> complexity. Additionally it’s not flexible enough to acknowledge that
>> there’s multiple types of site icons in use on the modern web, nor to
>> adapt to the embedding client’s need for customization.
>> 
>> I recently introduced the “_WKIconLoadingDelegate” model to
>> WebKit2Cocoa.
>> 
>> WebCore gathers all of the candidate icon URLs and asks the embedding
>> app for each one whether or not it wants to load them.
>> If the app says yes, the icon will be loaded as a subresource in the
>> current document and the data will be handed off to the client.
> 
> Do we have any cache here? would we use the disk cache like with any
> other subresource?

As noted, they are loaded as subresources in the current document.
As such, they go through the memory cache and disk cache.

Note: IconDatabase loads actually worked the same way.

>> If not, I can get rid of it right now
>> 
>> If so, then I need a GTK maintainer to come up with a plan soon.
> 
> How soon is soon? :-) We are approaching the end of our release cycle,
> it would be good for us if we could do any changes related to this
> after we branch for 2.18. Of course I can branch earlier if needed.
> According to our schedule we should branch the first week of August. Is
> that late?

That’s much later than the soon I was targeting.

Hoping to do this by the end of June.

>> The icon load delegate mechanism is powerful enough to rebuild an
>> IconDatabase on top of, so if GTK needs to keep this API functional
>> they can do so - maintaining the actual IconDatabase code themselves
>> up in their API layer.
> 
> I have to look at it in detail. If I can use the new mechanism to
> reimplement WebKitFaviconDatabase, I'll definitely do that. But if
> there's no longer a database of favicons, I wouldn't mind to deprecate
> it and provide a new better API. But in any case, I need to keep
> WebKitFaviconDatabase working, whether using new way or moving the
> current IconDatabase to wk2gtk.

The new mechanism definitely provides all of the signaling necessary to reimplement the current IconDatabase, but a little plumbing will be involved.

Thanks,
~Brady