Well I'm not sure if this would work or not. Left a comment at
https://github.com/WebKit/WebKit/pull/42334#issuecomment-2723224554
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
On Tue, Feb 18 2025 at 11:00:05 AM -06:00:00, Michael Catanzaro
wrote:
We should try to reimplement the sync APIs using the async APIs so we
don't have to remove them. The challenge here is we have to do that
*without* iterating the global RunLoop (otherwise, application
callbacks will be disp
On 2025-02-17 19:12, Alex Christensen via webkit-dev wrote:
> Since the introduction of WKDownload in 2020, I’ve been trying to make the
> download object creation process asynchronous in WebKit. With 290510@main
> I’ve removed the last caller of WebProcessPool::download from the Cocoa
> platfo
I’d be fine with having a transition period where both old and new APIs work,
then possibly another transition period where old APIs exist as deprecated
stubs that don’t work before removing them. It’s also possible we could add
glib-specific synchronous IPC to support the old APIs during this
Hm, we'll need to investigate this.
Deprecating APIs is easy. Adding newer replacements is often easy. But
removing APIs is extremely disruptive; we don't want to do that unless
there is absolutely no viable alternative. It requires an API version
bump, which requires changes in every applic
Since the introduction of WKDownload in 2020, I’ve been trying to make the
download object creation process asynchronous in WebKit. With 290510@main I’ve
removed the last caller of WebProcessPool::download from the Cocoa platform,
but I noticed that the glib APIs have 3 places where a WebKitDow
6 matches
Mail list logo
