Is the intention that NSURLSession should be implemented by wrapping libcurl?
If so, I'm tempted to take a stab at this.
/Daniel
I dont think we had an intention set forth for how that was to be implemented; honestly it was a bit of a “we dont know how this should be done for linux yet” when the initial API drafts were posted. That being said NSURLSession and friends are definitely pretty important areas in Foundation (hence why the placeholder implementations are there).
libcurl is readily available for linux (but we would need to alter our dependencies list for apt-get) and also is shipped for Darwin targets as well. so in spirit it might be a decent place to start.
There are a few places that might need some research on how to approach an implementation:
1) Can curl’s APIs interface with run loops?
2) Can curl’s API provide a reasonable implementation to back other APIs? NSURLCache, NSURLRequest, NSURLResponse, even older APIs like NSURLConnection?
3) How would the background downloading part of NSURLSession be handled? Would it just elide that feature?
4) Can it handle the delegation protocols for all events? If not, can the events be synthesized?
···
On Mar 14, 2016, at 2:05 AM, Daniel Eggert via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Is the intention that NSURLSession should be implemented by wrapping libcurl?
If so, I'm tempted to take a stab at this.
/Daniel
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
I dont think we had an intention set forth for how that was to be implemented; honestly it was a bit of a “we dont know how this should be done for linux yet” when the initial API drafts were posted. That being said NSURLSession and friends are definitely pretty important areas in Foundation (hence why the placeholder implementations are there).
libcurl is readily available for linux (but we would need to alter our dependencies list for apt-get) and also is shipped for Darwin targets as well. so in spirit it might be a decent place to start.
There are a few places that might need some research on how to approach an implementation:
1) Can curl’s APIs interface with run loops?
It interfaces very nicely with libdispatch -- is that an option?
2) Can curl’s API provide a reasonable implementation to back other APIs? NSURLCache, NSURLRequest, NSURLResponse, even older APIs like NSURLConnection?
As for NSURLRequest and NSURLResponse: These will need some 'glue' but should work nicely with libcurl's interface.
NSURLConnection is a bit of an oddball due it it's ties to NSRunLoop -- but it can certainly be made to work with libcurl.
NSURLCache: libcurl does not do any caching, and as a result the interaction with NSURLCache should be relatively straight forward.
libcurl's COOKIELIST should be able to interact with NSHTTPCookieStorage:
https://curl.haxx.se/libcurl/c/CURLOPT_COOKIELIST.html
3) How would the background downloading part of NSURLSession be handled? Would it just elide that feature?
I would elide that for now. To support this, we'd need an independent daemon to do the downloading. That's quite a project on its own.
4) Can it handle the delegation protocols for all events? If not, can the events be synthesized?
It appears that this should work nicely. libcurl provides callbacks as headers are parsed.
One main pinpoint will be SSL / TLS support. That'll depend entirely on how libcurl is compiled and will not be able to pick up TLSMinimumSupportedProtocol / TLSMaximumSupportedProtocol. Also interaction with the NSURLAuthenticationChallenge and TLS remains a question. libcurl does provide a hook for this, but it's not trivial since the code will have to interact with the underlying TLS implementation.
Any implementation will depend on NSOperation / NSOperationQueue -- and those will in turn to some extend depend on libdispatch being available.
And once libdispatch is available, it makes sense to use it for libcurl, too.
/Daniel
···
On 14 Mar 2016, at 15:36, Philippe Hausler <phausler@apple.com> wrote:
I dont think we had an intention set forth for how that was to be implemented; honestly it was a bit of a “we dont know how this should be done for linux yet” when the initial API drafts were posted. That being said NSURLSession and friends are definitely pretty important areas in Foundation (hence why the placeholder implementations are there).
libcurl is readily available for linux (but we would need to alter our dependencies list for apt-get) and also is shipped for Darwin targets as well. so in spirit it might be a decent place to start.
There are a few places that might need some research on how to approach an implementation:
1) Can curl’s APIs interface with run loops?
It interfaces very nicely with libdispatch -- is that an option?
We have not yet fully integrated libdispatch support on linux yet. It is very close and hopefully should be integrated soon.
2) Can curl’s API provide a reasonable implementation to back other APIs? NSURLCache, NSURLRequest, NSURLResponse, even older APIs like NSURLConnection?
As for NSURLRequest and NSURLResponse: These will need some 'glue' but should work nicely with libcurl's interface.
NSURLConnection is a bit of an oddball due it it's ties to NSRunLoop -- but it can certainly be made to work with libcurl.
NSURLCache: libcurl does not do any caching, and as a result the interaction with NSURLCache should be relatively straight forward.
libcurl's COOKIELIST should be able to interact with NSHTTPCookieStorage:
CURLOPT_COOKIELIST3) How would the background downloading part of NSURLSession be handled? Would it just elide that feature?
I would elide that for now. To support this, we'd need an independent daemon to do the downloading. That's quite a project on its own.
That is a fair assertion; perhaps as a decent implementation in the interim a dedicated thread for sessions could be set aside to simulate a different process. That way when someone decides to pick up the torch and factor it out to a daemon it wont be a huge disruption.
4) Can it handle the delegation protocols for all events? If not, can the events be synthesized?
It appears that this should work nicely. libcurl provides callbacks as headers are parsed.
One main pinpoint will be SSL / TLS support. That'll depend entirely on how libcurl is compiled and will not be able to pick up TLSMinimumSupportedProtocol / TLSMaximumSupportedProtocol. Also interaction with the NSURLAuthenticationChallenge and TLS remains a question. libcurl does provide a hook for this, but it's not trivial since the code will have to interact with the underlying TLS implementation.
Any implementation will depend on NSOperation / NSOperationQueue -- and those will in turn to some extend depend on libdispatch being available.
NSOQ requires dispatch to be implemented properly so that has been on hold.
And once libdispatch is available, it makes sense to use it for libcurl, too.
/Daniel
Overall I think this might be a decent place to start; and it seems to be a sensible approach. Integrating it for linux builds might be held up a bit until we can get libdispatch fully integrated.
···
On Mar 14, 2016, at 8:50 AM, Daniel Eggert <danieleggert@me.com> wrote:
On 14 Mar 2016, at 15:36, Philippe Hausler <phausler@apple.com> wrote:
Absolutely on point: I think it would be reasonable to make a new type to handle the interface layer _CFURLSession etc; that way some of the simple interfaces can be kept in C to the libcurl layer.
Testing is very important; however the major consideration I would suggest to take into account is try to keep it as simple as possible. Networking is hard to get right and verification is important. If at all possible eliminate as many variables as you can. It might be reasonable to spawn a small process off to deal with the server side of things if you don’t want to assume the network itself is something that needs to be tested.
As many tests that can be self contained as possible would be best. But it might be safe to assume that swift.org <http://swift.org/> is up.
···
On Mar 14, 2016, at 10:29 AM, Robert Stephen Thompson via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Just a couple of tips based on my experience wrapping libxml2 for NSXMLDocument:
1. You’ll need to actually import and link libcurl with CoreFoundation instead of trying to make a libcurl module.modulemap and importing it directly. This is because if you do it that way, you’ll have to add libcurl as a dependency _throughout_ the Swift build process, and it would all be pretty disruptive (and difficult to do).
2. As a consequence of 1., you’ll need to wrap every function you call from libcurl in a new CoreFoundation API. See CFXMLInterface.h and CFXMLInterface.c for what I mean. Of course, this also gives you the opportunity to add nullability annotations, wrap things in CFString, CFError, CFArray, etc, so it’s not just busy-work for getting around the build system, heh. Just depends on how much C you want to write, you could just straight wrap the libcurl functions and do everything in Swift, but at the very least nullability annotations are a win here.Thanks,
Robert Thompson
Software Engineer
WillowTree, Inc.®
willowtreeapps.com <http://willowtreeapps.com/>On Mar 14, 2016, at 11:50 AM, Daniel Eggert via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
On 14 Mar 2016, at 15:36, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:
I dont think we had an intention set forth for how that was to be implemented; honestly it was a bit of a “we dont know how this should be done for linux yet” when the initial API drafts were posted. That being said NSURLSession and friends are definitely pretty important areas in Foundation (hence why the placeholder implementations are there).
libcurl is readily available for linux (but we would need to alter our dependencies list for apt-get) and also is shipped for Darwin targets as well. so in spirit it might be a decent place to start.
There are a few places that might need some research on how to approach an implementation:
1) Can curl’s APIs interface with run loops?
It interfaces very nicely with libdispatch -- is that an option?
2) Can curl’s API provide a reasonable implementation to back other APIs? NSURLCache, NSURLRequest, NSURLResponse, even older APIs like NSURLConnection?
As for NSURLRequest and NSURLResponse: These will need some 'glue' but should work nicely with libcurl's interface.
NSURLConnection is a bit of an oddball due it it's ties to NSRunLoop -- but it can certainly be made to work with libcurl.
NSURLCache: libcurl does not do any caching, and as a result the interaction with NSURLCache should be relatively straight forward.
libcurl's COOKIELIST should be able to interact with NSHTTPCookieStorage:
CURLOPT_COOKIELIST3) How would the background downloading part of NSURLSession be handled? Would it just elide that feature?
I would elide that for now. To support this, we'd need an independent daemon to do the downloading. That's quite a project on its own.
4) Can it handle the delegation protocols for all events? If not, can the events be synthesized?
It appears that this should work nicely. libcurl provides callbacks as headers are parsed.
One main pinpoint will be SSL / TLS support. That'll depend entirely on how libcurl is compiled and will not be able to pick up TLSMinimumSupportedProtocol / TLSMaximumSupportedProtocol. Also interaction with the NSURLAuthenticationChallenge and TLS remains a question. libcurl does provide a hook for this, but it's not trivial since the code will have to interact with the underlying TLS implementation.
Any implementation will depend on NSOperation / NSOperationQueue -- and those will in turn to some extend depend on libdispatch being available.
And once libdispatch is available, it makes sense to use it for libcurl, too.
/Daniel
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Just a couple of tips based on my experience wrapping libxml2 for NSXMLDocument:
1. You’ll need to actually import and link libcurl with CoreFoundation instead of trying to make a libcurl module.modulemap and importing it directly. This is because if you do it that way, you’ll have to add libcurl as a dependency _throughout_ the Swift build process, and it would all be pretty disruptive (and difficult to do).
2. As a consequence of 1., you’ll need to wrap every function you call from libcurl in a new CoreFoundation API. See CFXMLInterface.h and CFXMLInterface.c for what I mean. Of course, this also gives you the opportunity to add nullability annotations, wrap things in CFString, CFError, CFArray, etc, so it’s not just busy-work for getting around the build system, heh. Just depends on how much C you want to write, you could just straight wrap the libcurl functions and do everything in Swift, but at the very least nullability annotations are a win here.
Thanks,
Robert Thompson
Software Engineer
WillowTree, Inc.®
willowtreeapps.com <http://willowtreeapps.com/>
···
On Mar 14, 2016, at 11:50 AM, Daniel Eggert via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On 14 Mar 2016, at 15:36, Philippe Hausler <phausler@apple.com> wrote:
I dont think we had an intention set forth for how that was to be implemented; honestly it was a bit of a “we dont know how this should be done for linux yet” when the initial API drafts were posted. That being said NSURLSession and friends are definitely pretty important areas in Foundation (hence why the placeholder implementations are there).
libcurl is readily available for linux (but we would need to alter our dependencies list for apt-get) and also is shipped for Darwin targets as well. so in spirit it might be a decent place to start.
There are a few places that might need some research on how to approach an implementation:
1) Can curl’s APIs interface with run loops?
It interfaces very nicely with libdispatch -- is that an option?
2) Can curl’s API provide a reasonable implementation to back other APIs? NSURLCache, NSURLRequest, NSURLResponse, even older APIs like NSURLConnection?
As for NSURLRequest and NSURLResponse: These will need some 'glue' but should work nicely with libcurl's interface.
NSURLConnection is a bit of an oddball due it it's ties to NSRunLoop -- but it can certainly be made to work with libcurl.
NSURLCache: libcurl does not do any caching, and as a result the interaction with NSURLCache should be relatively straight forward.
libcurl's COOKIELIST should be able to interact with NSHTTPCookieStorage:
CURLOPT_COOKIELIST3) How would the background downloading part of NSURLSession be handled? Would it just elide that feature?
I would elide that for now. To support this, we'd need an independent daemon to do the downloading. That's quite a project on its own.
4) Can it handle the delegation protocols for all events? If not, can the events be synthesized?
It appears that this should work nicely. libcurl provides callbacks as headers are parsed.
One main pinpoint will be SSL / TLS support. That'll depend entirely on how libcurl is compiled and will not be able to pick up TLSMinimumSupportedProtocol / TLSMaximumSupportedProtocol. Also interaction with the NSURLAuthenticationChallenge and TLS remains a question. libcurl does provide a hook for this, but it's not trivial since the code will have to interact with the underlying TLS implementation.
Any implementation will depend on NSOperation / NSOperationQueue -- and those will in turn to some extend depend on libdispatch being available.
And once libdispatch is available, it makes sense to use it for libcurl, too.
/Daniel
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
I have three questions:
(1) What would be a reasonable way to add tests? Should I add an in-process HTTP server. Something along the lines of
(2) How would I go about pulling in libcurl? I could add
#include <curl/curl.h>
to ForSwiftFoundationOnly.h -- but I'd also need to add helpers for variadic function like so:
static inline CURLcode curl_easy_setopt_ptr(CURL *_Nonnull curl, CURLoption option, void *_Nullable a) {
return curl_easy_setopt(curl, option, a);
}
static inline CURLcode curl_easy_setopt_int(CURL *_Nonnull curl, CURLoption option, int a) {
return curl_easy_setopt(curl, option, a);
}
static inline CURLcode curl_easy_setopt_wc(CURL *_Nonnull curl, CURLoption option, size_t(*_Nullable a)(char *_Nonnull, size_t, size_t, void *_Nullable)) {
return curl_easy_setopt(curl, option, a);
}
where should these go?
(3) Is it ok for me to split the libcurl specific code into a separate file, or should I try to keep everything inside NSURLSession.swift?
/Daniel
···
On 14 Mar 2016, at 17:43, Philippe Hausler <phausler@apple.com> wrote:
[...]
Overall I think this might be a decent place to start; and it seems to be a sensible approach. Integrating it for linux builds might be held up a bit until we can get libdispatch fully integrated.
Is it ok for me to split the libcurl specific code inside Foundation into a separate file, say NSURLSession+curl.swift ? Or should I try to keep everything inside NSURLSession.swift ?
If I go for a separate file, I'd be able to differentiate between internal and private for the helpers. I'll end up close to 1000 lines of code for this. Having these inside NSURLSession.swift is a bit overwhelming.
/Daniel
I just looked at this, and libxml2 is being linked against by SwiftFoundation, and NOT by CoreFoundation -- on Darwin.
Is the correct approach to do what's been done with libxml2, or should I instead have CoreFoundation link against libcurl?
/Daniel
···
On 14 Mar 2016, at 18:29, Robert Stephen Thompson <robert.thompson@willowtreeapps.com> wrote:
Just a couple of tips based on my experience wrapping libxml2 for NSXMLDocument:
1. You’ll need to actually import and link libcurl with CoreFoundation instead of trying to make a libcurl module.modulemap and importing it directly. This is because if you do it that way, you’ll have to add libcurl as a dependency _throughout_ the Swift build process, and it would all be pretty disruptive (and difficult to do).
2. As a consequence of 1., you’ll need to wrap every function you call from libcurl in a new CoreFoundation API. See CFXMLInterface.h and CFXMLInterface.c for what I mean. Of course, this also gives you the opportunity to add nullability annotations, wrap things in CFString, CFError, CFArray, etc, so it’s not just busy-work for getting around the build system, heh. Just depends on how much C you want to write, you could just straight wrap the libcurl functions and do everything in Swift, but at the very least nullability annotations are a win here.
That seems pretty reasonable to me, I guess the only thing to watch out for is private vs internal.
···
Sent from my iPhone
On Mar 15, 2016, at 2:44 AM, Daniel Eggert <danieleggert@me.com> wrote:
Is it ok for me to split the libcurl specific code inside Foundation into a separate file, say NSURLSession+curl.swift ? Or should I try to keep everything inside NSURLSession.swift ?
If I go for a separate file, I'd be able to differentiate between internal and private for the helpers. I'll end up close to 1000 lines of code for this. Having these inside NSURLSession.swift is a bit overwhelming.
/Daniel
I’ve made good progress on this. I’ll try to get something that’s merge-able within the next week. It won’t be 100% complete by any means, but should hopefully (A) cover the most common use cases, and (B) be a solid basis for the remaining functionality.
/Daniel
···
On 15 Mar 2016, at 15:12, Philippe Hausler <phausler@apple.com> wrote:
That seems pretty reasonable to me, I guess the only thing to watch out for is private vs internal.
Sent from my iPhone
On Mar 15, 2016, at 2:44 AM, Daniel Eggert <danieleggert@me.com> wrote:
Is it ok for me to split the libcurl specific code inside Foundation into a separate file, say NSURLSession+curl.swift ? Or should I try to keep everything inside NSURLSession.swift ?
If I go for a separate file, I'd be able to differentiate between internal and private for the helpers. I'll end up close to 1000 lines of code for this. Having these inside NSURLSession.swift is a bit overwhelming.
/Daniel
The swift-corelibs-foundation version of CF is a static library that is being built into the Foundation product dynamic library so the linkage for libxml2 and anything else should be on that.
The layout of how linking works for the Darwin version is different because of how we split the layers. NSXMLParser is based on libxml2 in objc. It just does not need a CF abstraction/thunks to convert types.
···
Sent from my iPhone
On Mar 23, 2016, at 4:07 AM, Daniel Eggert via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On 14 Mar 2016, at 18:29, Robert Stephen Thompson <robert.thompson@willowtreeapps.com> wrote:
Just a couple of tips based on my experience wrapping libxml2 for NSXMLDocument:
1. You’ll need to actually import and link libcurl with CoreFoundation instead of trying to make a libcurl module.modulemap and importing it directly. This is because if you do it that way, you’ll have to add libcurl as a dependency _throughout_ the Swift build process, and it would all be pretty disruptive (and difficult to do).
2. As a consequence of 1., you’ll need to wrap every function you call from libcurl in a new CoreFoundation API. See CFXMLInterface.h and CFXMLInterface.c for what I mean. Of course, this also gives you the opportunity to add nullability annotations, wrap things in CFString, CFError, CFArray, etc, so it’s not just busy-work for getting around the build system, heh. Just depends on how much C you want to write, you could just straight wrap the libcurl functions and do everything in Swift, but at the very least nullability annotations are a win here.I just looked at this, and libxml2 is being linked against by SwiftFoundation, and NOT by CoreFoundation -- on Darwin.
Is the correct approach to do what's been done with libxml2, or should I instead have CoreFoundation link against libcurl?
/Daniel
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Looking at the swift-corelibs-foundation Xcode project, the "Link Binary With Libraries" is empty for the CoreFoundation target, while it contains libxml2 for the SwiftFoundation target.
I'd do the same for libcurl.
/Daniel
···
On 23 Mar 2016, at 14:44, Philippe Hausler <phausler@apple.com> wrote:
The swift-corelibs-foundation version of CF is a static library that is being built into the Foundation product dynamic library so the linkage for libxml2 and anything else should be on that.
The layout of how linking works for the Darwin version is different because of how we split the layers. NSXMLParser is based on libxml2 in objc. It just does not need a CF abstraction/thunks to convert types.
Awesome, thanks for taking this on!
- Tony
···
On Mar 17, 2016, at 12:33 PM, Daniel Eggert via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
I’ve made good progress on this. I’ll try to get something that’s merge-able within the next week. It won’t be 100% complete by any means, but should hopefully (A) cover the most common use cases, and (B) be a solid basis for the remaining functionality.
/Daniel
On 15 Mar 2016, at 15:12, Philippe Hausler <phausler@apple.com> wrote:
That seems pretty reasonable to me, I guess the only thing to watch out for is private vs internal.
Sent from my iPhone
On Mar 15, 2016, at 2:44 AM, Daniel Eggert <danieleggert@me.com> wrote:
Is it ok for me to split the libcurl specific code inside Foundation into a separate file, say NSURLSession+curl.swift ? Or should I try to keep everything inside NSURLSession.swift ?
If I go for a separate file, I'd be able to differentiate between internal and private for the helpers. I'll end up close to 1000 lines of code for this. Having these inside NSURLSession.swift is a bit overwhelming.
/Daniel
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
I've created this pull request in an attempt to get more feedback on my approach. I hope this is in line with the contribution guidelines.
https://github.com/apple/swift-corelibs-foundation/pull/299
This is will work-in-progress and marked as such.
/Daniel
Changes since last week:
NSURLSessionDataTask (i.e. GET requests) now work with callbacks and with completion handler.
Debug output is enabled by environment variables.
Handling a few common error scenarios to return the corresponding NSError.
/Daniel
I won't be able to put too many more hours into this after next week.
Feedback is very welcome.
The tests show what's working, and there are "TODO:" markers throughout the code where applicable.
/Daniel
I think that’s a fair approach - but does this even compile on Linux without dispatch in place? I get “no such module ‘Dispatch’” errors when compiling.
- Tony
···
On Apr 18, 2016, at 11:24 AM, Pushkar N Kulkarni <pushkar.nk@in.ibm.com> wrote:
Thanks for your great work on NSURLSession and friends, Daniel!
I was wondering if we are only waiting for dispatch to be available on Linux here. In that case, could we have the failing tests (if any) excluded (only on Linux perhaps) and have this merged please? Some of us at IBM would like to work with the current implementation and contribute on top of it.
Thanks!
Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-----swift-corelibs-dev-bounces@swift.org <mailto:-----swift-corelibs-dev-bounces@swift.org> wrote: -----
To: Swift corelibs dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
From: Daniel Eggert via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org <mailto:swift-corelibs-dev-bounces@swift.org>
Date: 04/05/2016 12:14AM
Subject: Re: [swift-corelibs-dev] NSURLSession & libcurlI won't be able to put too many more hours into this after next week.
Feedback is very welcome.
The tests show what's working, and there are "TODO:" markers throughout the code where applicable.
/Daniel
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Thanks for your great work on NSURLSession and friends, Daniel!
I was wondering if we are only waiting for dispatch to be available on Linux here. In that case, could we have the failing tests (if any) excluded (only on Linux perhaps) and have this merged please? Some of us at IBM would like to work with the current implementation and contribute on top of it.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
I won't be able to put too many more hours into this after next week.
https://github.com/apple/swift-corelibs-foundation/pull/299
Feedback is very welcome.
The tests show what's working, and there are "TODO:" markers throughout the code where applicable.
/Daniel
···
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
To: Swift corelibs dev swift-corelibs-dev@swift.org
From: Daniel Eggert via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 04/05/2016 12:14AM
Subject: Re: [swift-corelibs-dev] NSURLSession & libcurl
-----swift-corelibs-dev-bounces@swift.org wrote: -----
I don't think it compiles, but I haven't tried, yet. I've been trying to keep it up-to-date with master.
/Daniel
···
On Apr 18, 2016, at 13:15, Tony Parker <anthony.parker@apple.com> wrote:
I think that’s a fair approach - but does this even compile on Linux without dispatch in place? I get “no such module ‘Dispatch’” errors when compiling.
- Tony
On Apr 18, 2016, at 11:24 AM, Pushkar N Kulkarni <pushkar.nk@in.ibm.com> wrote:
Thanks for your great work on NSURLSession and friends, Daniel!
I was wondering if we are only waiting for dispatch to be available on Linux here. In that case, could we have the failing tests (if any) excluded (only on Linux perhaps) and have this merged please? Some of us at IBM would like to work with the current implementation and contribute on top of it.
Thanks!
Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-----swift-corelibs-dev-bounces@swift.org wrote: -----
To: Swift corelibs dev <swift-corelibs-dev@swift.org>
From: Daniel Eggert via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 04/05/2016 12:14AM
Subject: Re: [swift-corelibs-dev] NSURLSession & libcurlI won't be able to put too many more hours into this after next week.
Feedback is very welcome.
The tests show what's working, and there are "TODO:" markers throughout the code where applicable.
/Daniel
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev