Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-10960] URLSessionConfiguration.background(withIdentifier) method implemented #2362

Conversation

karthikkeyan
Copy link
Contributor

@karthikkeyan karthikkeyan changed the title URLSessionConfiguration.background(withIdentifier) method implemented [SR-10960] URLSessionConfiguration.background(withIdentifier) method implemented Jun 18, 2019
@karthikkeyan karthikkeyan force-pushed the karthik/urlsessionconfiguration-background-SR-10960 branch from 96b3a26 to 0d23a4e Compare June 18, 2019 13:56
@karthikkeyan
Copy link
Contributor Author

cc @pushkarnk

@pushkarnk
Copy link
Collaborator

@karthikkeyan Thanks for taking this up. I understand this is for the sake of API parity. But whether the concept of a background task should to be supported on Linux/Windows is a big question that needs a discussion. I guess, background tasks may be relevant in the Swift on Android context though.

Before we start implementing bits of this, it may be a good idea a start a discussion and decide on if, and how, we are going to support background tasks on non-Darwin platforms. This is my opinion. I'm eager to know what you, and others, think about this.

P.S: I recall this discussion from the very early days :)

@karthikkeyan
Copy link
Contributor Author

@karthikkeyan Thanks for taking this up. I understand this is for the sake of API parity. But whether the concept of a background task should to be supported on Linux/Windows is a big question that needs a discussion. I guess, background tasks may be relevant in the Swift on Android context though.

Before we start implementing bits of this, it may be a good idea a start a discussion and decide on if, and how, we are going to support background tasks on non-Darwin platforms. This is my opinion. I'm eager to know what you, and others, think about this.

P.S: I recall this discussion from the very early days :)

@pushkarnk Yes, I also had the same doubt, but I thought it wouldn't hurt to give it a try, so I had created this PR. We don't have to review or work on this PR if now is not an appropriate time for it. Thanks for sharing thread link, I have also created a thread as well here. I will follow both of them.

@@ -156,7 +156,17 @@ open class URLSessionConfiguration : NSObject, NSCopying {
return ephemeralConfiguration
}

open class func background(withIdentifier identifier: String) -> URLSessionConfiguration { NSUnimplemented() }
open class func background(withIdentifier identifier: String) -> URLSessionConfiguration {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not have a daemon handling background sessions outside of Darwin. This should be marked @availability(*, unavailable) with a message.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@millenomi I have reverted the implementation and added @available(*, unavailable, message: "Not available on non-Darwin platforms")

Copy link
Contributor

@millenomi millenomi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above.

@millenomi
Copy link
Contributor

If an API does something that has strong guarantees, we strive to implement the same guarantees. .background(…) creates sessions that the developer expects to complete after the process is killed, and we cannot guarantee that happens without the infrastructure Darwin provides. We should not attempt to make it available this way; instead, a user who is porting code that requires background sessions can sit down and evaluate if they are using background sessions because they rely on these semantics (and restructure their code to match the fact they aren't available) vs. using them because they benefit from those semantics but could still port this code if this was a regular URLSession.

…ce it only supported by Darwin infrastructure.
@millenomi
Copy link
Contributor

@swift-ci please test Linux

@millenomi
Copy link
Contributor

@swift-ci please test Linux

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants