[webkit-dev] Glib download API change request

[Alex Christensen]

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 transition period.  The point I’m trying to make is that we need to do IPC roundtrips before creating a DownloadProxy, and we need to have a path towards aligning our API shapes when it becomes problematic to support differently shaped APIs.

> On Feb 18, 2025, at 9:00 AM, Michael Catanzaro <mcatanzaro at redhat.com> wrote:
> 
> 
> 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 application that depends on WebKitGTK/WPE even if they don't use the affected API, and new parallel packaging in every downstream.
> 
> 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 dispatched at unexpected times, and all manner of bugs could occur, including memory corruption and other vulnerabilities). So we need to do this using a "private" RunLoop. In Linux-specific code, we would do this easily by using GMainContext directly; we would create a new GMainContext, push it as thread-default, iterate it until the async operation has completed, and then pop it, thereby creating a synchronous wrapper around an async function call. But I don't think it can be done without changes in WebKit's RunLoop. RunLoop does not have any equivalent concept to allow temporarily making a different RunLoop the "current" default RunLoop for a thread, which is what we need here. It's probably doable, though.
> 
> Once before, sometime rather recently (maybe 6-12 months ago?), we gave up on doing this properly and landed a patch that iterates the global run loop behind the application's back in order to fix some bug. I don't remember what particular bug it was, but I was opposed to doing that; it's really not safe.
> 
> If you're OK with keeping the existing synchronous code around, it would be less work to just maintain separate sync and async paths. We'll remove all deprecated APIs in the far distant future, next time we bump API version; we could add a comment to delete the sync versions then.
> 
> Michael
> 
>