<html><body><p>To prepare for the Security Group meeting tomorrow, we put together a quick write up of our experience when coming up with consistent Swift APIs for TLS support in Kitura.<br><br><a href="https://developer.ibm.com/swift/2016/12/13/securing-kitura-cross-platform-challenges/">https://developer.ibm.com/swift/2016/12/13/securing-kitura-cross-platform-challenges/</a><br><br>Gelareh<br><br><br><img width="16" height="16" src="cid:1__=8FBB0A1BDFC53FE88f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Bill Abt via swift-server-dev ---11/12/2016 10:01:00 AM---I absolutely agree. Why re-invent the whee"><font color="#424282">Bill Abt via swift-server-dev ---11/12/2016 10:01:00 AM---I absolutely agree. Why re-invent the wheel? Existing libraries that would be chosen are most like</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Bill Abt via swift-server-dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Chris Lattner <clattner@apple.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Swift Server Dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">11/12/2016 10:01 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [swift-server-dev] Crypto Library</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">swift-server-dev-bounces@swift.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>I absolutely agree. Why re-invent the wheel? Existing libraries that would be chosen are most likely “battle tested and proven”. To redo all that in Swift seems to me to be a waste of valuable time. There’s a lot more other work that needs to be done to make server side Swift successful and if that means reusing and leveraging existing “C” code, so be it.<br><br>-Bill Abt<br><br>> On Nov 10, 2016, at 3:02 PM, Chris Lattner via swift-server-dev <swift-server-dev@swift.org> wrote:<br>> <br>> <br>>> On Nov 8, 2016, at 2:18 PM, Helge Heß via swift-server-dev <swift-server-dev@swift.org> wrote:<br>>> <br>>> On 8 Nov 2016, at 16:45, Chris Bailey via swift-server-dev <swift-server-dev@swift.org> wrote:<br>>>> Whilst there's legitimate debate on the use of C vs. Swift for HTTP parsing, I think the situation for the security libraries in general is more clear.<br>>> <br>>> This is really a bit off topic but I disagree with that. Either you:<br>>> a) are OK with C libs and deal with it<br>>> b) deal with C libs as a temporary measure but the goal is Swift<br>>> c) reject C libs from the start<br>> <br>> Just my personal opinion, but I don’t see why “pure swift” is a goal or even interesting to thing about. The goal should be provide expressive and natural Swift APIs for server development tasks. The implementation should not show through that API.<br>> <br>> If (and only if) there is some advantage to rewriting C code in Swift (e.g. for performance, memory, correctness, or capability reasons) then it is certainly interesting to talk about that of course.<br>> <br>> A relevant comparison is to corelibs-foundation, which uses a significant amount of C code in its implementation. <br>> <br>> -Chris<br>> _______________________________________________<br>> swift-server-dev mailing list<br>> swift-server-dev@swift.org<br>> </tt><tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></tt><tt><br><br>_______________________________________________<br>swift-server-dev mailing list<br>swift-server-dev@swift.org<br></tt><tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></tt><tt><br></tt><br><br><BR>
</body></html>