[swift-corelibs-dev] NSURLSession & libcurl

[Philippe Hausler]

> On Mar 14, 2016, at 8:50 AM, Daniel Eggert <danieleggert at me.com> wrote:
> 
> 
>> On 14 Mar 2016, at 15:36, Philippe Hausler <phausler at 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:
> 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.

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.