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

[Carlos Garcia Campos]

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?

> From Apple’s perspective:
> 
> The new model is powerful and flexible enough that Safari has adopted
> it.
> 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
> “WebKitFaviconDatabase”
> 
> 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
compatibility.

> 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?

> 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.

> Thanks,
> ~Brady
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev