<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>Hey Joannis! Nice to see you here. đ<br><br>I agree with you 100â
we shouldn't rush the design of the APIs. I didn't mean that at all. I meant exactly the opposite. We should spend as much time as possible on the API design, and wrapping a C library would allows to distribute our total time of development focusing a lot more on the API design than on the development and maintenance of the internals. We should definitely design the API with the best of Swift using protocols and everything else you mentioned, and wraping C doesn't restrain us in any way to do that. There's nothing we can't do on the API level because we're wrapping C. What Chris Bailey mentioned about my mentality before is totally right. I believe we should spend as much time as possible designing the APIs without any constraint from, for example, Foundation or any C library, and in the Foundation case if really needed we should compromise. I just know from experience that wrapping C libs doesn't constraint at all the "Swiftyness" of the user-facing API. This is pure conjecture as I didn't really dig in, but I believe Swift's standard library itself uses libicu for String's internal on Linux. If this is wrong someone please correct me. I also believe Foundation wraps libcurl for the HTTP stuff.<div id="message"></div><br id="br3"><div id="signature"></div><div id="content"><blockquote><br> ---- On Sun, 06 Nov 2016 07:54:15 -0200 <b> joannis@orlandos.nl </b> wrote ----<br><br><meta><div style=""><div><div>I think that if you wrap C libraries you'll get stuck in the wrong mentality. Working with C libraries encourages thinking without protocols. Protocols like `ExpressibleByDictionaryLiteral` and `Sequence` are really easy to implement and make usage of conforming types really beautiful. I think that a lot of APIs will be designed with the wrong mentality, at least initially, because they're alien to Swift. And that'll create APIs for these libraries that are not at the level where they could be in a language like Swift.</div></div><div><br></div><div>I don't think we need to rush ourselves with trying to create the libraries rapidly. If you want to have a common set of libraries in which the entire community will cooperate I think Swift is the only way to go. Many people have already written big libraries and frameworks in Swift. And I myself would never remove my own Swift code in favour of C-reliant code. And I doubt it's just me. I think that people whom prefer pure Swift will stick with (their own) existing functionality and rather build on top of a C reliant codebase.</div><div><br></div><div>Besides that all I feel like there's no need to rush it. A good set of libraries needs time. If you have a million people working on something for a week it will never be as good as a hundred people for a year or two. A good API/library needs time to be thought out and will need more than a few nights of rest before I think the idea alone should be considered complete. I think this counts for C-based and pure Swift libraries.</div><div><br></div><div>And if we'd just take the time to develop something great it will have a much greater impact on the Server Side Swift world than it would otherwise.</div><div><br></div><div>Joannis</div><br><div><blockquote><div>On 6 Nov 2016, at 10:44, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:</div><br><div><font size="2" face="sans-serif">Whilst it might not feel like it, it seems to be that we're all pulling in the same direction.</font> <br> <br><font size="2" face="sans-serif">Tony said:</font> <br><font size="2">>> I think if the API design feels âalienâ to Foundation, then we either need to update the Foundation API to feel like it fits in with Swift or design the server API to fit in with Foundation.<br> <br> >> Iâll keep pushing for this throughout the process. Itâs really important that we have a coherent stack of software from top to bottom. Ending up with different model objects for URLRequest used in the same app via two frameworks would be really unfortunate.<br> </font> <br><font size="2" face="sans-serif">I think this completely aligns with what everyone is saying - we want/need a coherent API stack with seamless interop between any new APIs and the existing ones. The only thing we need to work on is the approach to achieving that.</font> <br> <br><font size="2" face="sans-serif">For me, and I think that this is the approach that Paulo is pushing for, is that we should first look at "what do we think is the right approach", without any constraints. Once we understand that, and any gap there is between that and the Foundation approach, we can determine how we close that gap - whether we can do that by evolving APIs, or whether it requires compromises for the sake of developer experience and application code portability, etc. </font> <br> <br><font size="2" face="sans-serif">Chris<br> </font> <br> <br> <br> <br><font size="1" color="#5f5f5f" face="sans-serif">From: </font><font size="1" face="sans-serif">Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>></font> <br><font size="1" color="#5f5f5f" face="sans-serif">To: </font><font size="1" face="sans-serif">Tony Parker <<a href="mailto:anthony.parker@apple.com" target="_blank">anthony.parker@apple.com</a>></font> <br><font size="1" color="#5f5f5f" face="sans-serif">Cc: </font><font size="1" face="sans-serif">Swift Server Dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>></font> <br><font size="1" color="#5f5f5f" face="sans-serif">Date: </font><font size="1" face="sans-serif">04/11/2016 23:08</font> <br><font size="1" color="#5f5f5f" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [swift-server-dev] HTTP Parser</font> <br><font size="1" color="#5f5f5f" face="sans-serif">Sent by: </font><font size="1" face="sans-serif"><a href="mailto:swift-server-dev-bounces@swift.org" target="_blank">swift-server-dev-bounces@swift.org</a></font> <br> <hr> <br> <br> <br><font size="3">> With respect to adopting other core Swift ideas like value types: we turned 20 classes into value types last year. This included a ton of work to adopt standard library protocols and improve type safety. It is an absolutely huge surface amount of Foundationâs total API surface area. Itâs a large statement about how much we value making Foundationâs API consistent for Swift.</font> <br> <br><font size="3">Yeah! I really love the effort youâre putting into making Foundation more âSwiftyâ. That doesnât go unnoticed. </font> <br> <br> <br><font size="3">On Nov 4, 2016, at 8:49 PM, Tony Parker <</font><a href="mailto:anthony.parker@apple.com" target="_blank"><font size="3" color="blue"><u></u></font></a><font size="3" color="blue"><u><a href="mailto:anthony.parker@apple.com" target="_blank">anthony.parker@apple.com</a></u></font><font size="3">> wrote:</font> <br> <br><font size="1" face="Helvetica">However, I do not believe there is such a fundamental conceptual mismatch here that we cannot preserve one of the most useful aspects of developing with the iOS, macOS SDKs - consistent types and low impedance mismatch between API at all levels of the stack.</font> <br> <br><font size="3">I definitely value "consistent types and low impedance mismatch between API at all levels of the stackâ. I just hope the APIs are designed with the best of Swift in mind. Then after we get a good design, we can see if it fits Foundation, and then make the adaptations there. I think this approach would make Foundation follow along and become even more âSwiftierâ with time. Of course this is easier said than done, but I believe thatâs what would make the ecosystem as a whole become better for Swift.</font><font size="2">_______________________________________________<br> swift-server-dev mailing list<br> <a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br> </font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target="_blank"><font size="2"></font></a><font size="2"><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></font><font size="2"><br> </font> <br> <br> _______________________________________________<br>swift-server-dev mailing list<br><a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br></div></blockquote></div><br></div></blockquote></div></div></body></html>