Version-3 ICoreWebView2WebResourceRequest and WKURLSchemeTask #2761
Replies: 1 comment
-
With regards to macOS version, our hands are tied to whatever Go supports. Currently that's 10.13, with Go 1.21 that'll be 10.15. With regards to using http+websocket, it's unlikely we will do this. There are a bunch of reasons not to open an http port in a desktop application and this would likely be a show-stopper for companies who currently use it. The current scheme approach is used in v2 with seemingly no issues. It is also the approach used by Tauri so it's a fairly standard approach. It sounds like you want is just a website with a client. Honestly, I'd look at using a standard Go web server and opening a view using something like webview to open that local port. Sounds like it's more suited to your scenario. Good luck 👍 |
Beta Was this translation helpful? Give feedback.
-
Hello, I am building a multi window desktop application using V3 version
Under MacOs, I found that the V3 version limits the minimum MacOS system version number to 10.13, but among my target users, there are many people whose versions cannot be upgraded because they use certain old versions of other software, which limits system upgrades.
In Windows, when making network requests, edge.ICoreWebView2WebResourceRequest is currently used for processing. I found that this method is synchronously processed in the interface thread of the form. If a new Goroutine is enabled to process requests, the return results will be unpredictable, so all requests must be processed synchronously. I'm not sure if I'm using the wrong method or if it's necessary
Therefore, I believe that we should abandon the use of WKURLSchemeTask and ICoreWebView2WebResourceRequest and use websocket+HTTP for communication, which can better compatibility with lower version systems. Although it may reduce some communication efficiency, I believe it is worth it. At the same time, it also reduces the special handling of requests by different platforms, making it simpler and easier to understand
On the other hand, some existing HTTP access methods with BS structure applications can also be migrated faster and simpler
In the process of development and debugging, the user interface and backend services are usually carried out by different personnel, and interface developers tend to use existing browsers for debugging and development. Therefore, using websocket+HTTP communication will be more in line with some existing development processes
Therefore, I suggest changing the communication mode of the V3 version to websocket+http mode
Beta Was this translation helpful? Give feedback.
All reactions