[swift-server-dev] Next Server Security API Group Meeting
Chris Bailey
BAILEYC at uk.ibm.com
Tue Jan 31 08:10:48 CST 2017
Agreed - the ability to run non-blocking definitely a goal.
Chris
From: Helge Heß via swift-server-dev <swift-server-dev at swift.org>
To: swift-server-dev <swift-server-dev at swift.org>
Date: 30/01/2017 10:59
Subject: Re: [swift-server-dev] Next Server Security API Group
Meeting
Sent by: swift-server-dev-bounces at swift.org
On 30 Jan 2017, at 10:59, Helge Heß <me at helgehess.eu> wrote:
> However, I thought - and I may be very wrong here, which would be
excellent - that SecurityFramework only supported blocking read and write
callbacks and cannot be ‘paused’ until new data arrives.
I’m just told off-list that this is not true. The lowest-level TLS API,
Secure Transport, can be used in a non-blocking mode. Things like
CFSocketStream and NSURLSession, actually use this facility to provide
their async abstractions.
So I guess everything will be fine. Still the TLS API draft for Swift
should state it as an explicit goal that it can be used in a non-blocking
fashion.
Thanks,
Helge
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170131/601a5b1b/attachment.html>
More information about the swift-server-dev
mailing list