[webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)
Carlos Garcia Campos
carlosgc at webkit.org
Thu Jun 15 22:59:11 PDT 2017
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
> 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
> From Apple’s perspective:
> The new model is powerful and flexible enough that Safari has adopted
> In WebKit1, the “WebIconDatabase” class was never API and is
> currently unused.
> In WebKit2, the C-API support was never API and is currently unused.
> Therefore we intend to remove the current WebCore IconDatabase from
> the project soon.
This is great news.
> Starting in on this task, I of course noticed GTK’s API has exposed
> Is that something that’s published API and that is used?
Yes, it is part of our public API, so we need to keep backwards
> 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
> 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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev