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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
