Seems unlikely, unless the SSWG has been given special privileges to evolve
URLSession outside of Apple's Foundation networking team. Unless you mean something else?
No Jon, I had nothing more than a question. And I understand your answer. Yet:
- URLSession is a frequent topic in these forums.
- https://github.com/apple/swift-corelibs-foundation is distinct from Apple's Foundation
- it's not about changing or creating apis, but changing the dependencies (if I have well understood Pitch: Move URLSession to new FoundationNetworking module)
This is not entirely true. As discussed in this thread, open source Foundation still must match the API of Darwin Foundation (Even if it doesn't have parity with it). That thread dives into discussion about alternatives approaches, but the fact remains that Foundation has a closed evolution.
That being said, what exactly about URLSession or its capabilities would you want to discuss as part of the work group? Because from reading the new work group goals, it sounds like building a new Swift library that could do URLSessiony type things is on the table. (Or by putting an already existing library through the work group process)
Hi. The goal of the Swift Server work group is to shepherd the development of server-side packages, from idea to recommendation.
In our discussions there was broad agreement that these packages should be delivered via Swift Package Manager, and should integrate well with SwiftNIO.
A client-side HTTP library has been suggested along with a lot of other potential ideas. I'm interested to see what the community thinks are the highest priority items.
I'd love to see a common HTTP package created on top of NIO that can be used in lieu of URLSession on Linux. It would be a big undertaking though. I think to do it right you'd want to define
HTTPResponse types (among many others) that should be adopted by or at least compatible with all of the Swift web frameworks. Vapor already has a library like this (vapor/http), but I'm hoping to propose a more generic version to the SSWG eventually.
Before that happens though, I think it's possible that some lower level things like logging and debugging should be tackled first. Like Ian said, I'm interested to see what the community thinks are the highest priority items.