<div dir="ltr"><div dir="ltr" class="gmail_msg">I think the most important aspect of these APIs that hasn't been mentioned is that they have to work for everyone. If they do not fit all the requirements out of the box, then they should at the very least be wrappable into doing so. In the case of value vs reference types, any value type can be made a reference type (via inout or a wrapper class) whereas the other way around is simply not possible. If higher level frameworks want reference type behavior because that's what they believe their users expect, then they should be free to do that while still taking advantage of these APIs. With that in mind I'd argue that it really doesn't matter which is more correct, but rather which is both flexible and performant.</div><div dir="ltr" class="gmail_msg"><br></div><div class="gmail_msg">Dan</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Mar 29, 2017 at 10:54 AM Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29. Mar 2017, at 19:14, Johannes Weiß <<a href="mailto:johannesweiss@apple.com" class="gmail_msg" target="_blank">johannesweiss@apple.com</a>> wrote:<br class="gmail_msg">
>> And we didn’t even discuss body streams yet, which I still find much more interesting due to the implications they can have on the I/O model :-) Paulo already mentioned the possible need for two APIs (async/sync), which matches my experience.<br class="gmail_msg">
><br class="gmail_msg">
> As per my email where I sketch what we use internally, we only have an async API. We have higher-level stuff on that and some does actually have sync APIs but why do you think we need both a sync and an async API? If someone wants a sync web framework, that's pretty simple to put on top of an async API.<br class="gmail_msg">
<br class="gmail_msg">
I’ve been thinking a lot about that lately (since well, one of my projects Noze.io is async to the core while my other, mod_swift, is completely sync for practical purposes). I do not think that it is easy at all to put a sync API on top of an async one. But maybe you can enlighten me :-)<br class="gmail_msg">
<br class="gmail_msg">
Yes, you can use a DispatchSemaphore to serialise the access and make GCD stuff work within sync environments, but as far as I can see this can’t be done in an automagic way right now. It would be cool if GCD would support that, something like a DispatchMain(), but more like WaitForEverythingScheduledFromThisThread().<br class="gmail_msg">
<br class="gmail_msg">
The other thing is that async (not NIO) essentially requires @escaping closures while sync stuff often doesn’t. @escaping is a pretty big big overhead.<br class="gmail_msg">
<br class="gmail_msg">
You can have the same user-facing API, like:<br class="gmail_msg">
<br class="gmail_msg">
readFile(“/etc/passwd”) { data in<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
but in a sync framework that would be<br class="gmail_msg">
<br class="gmail_msg">
func readFile(_ p: String, cb: (Data)->Void)<br class="gmail_msg">
<br class="gmail_msg">
in an async framework it would be<br class="gmail_msg">
<br class="gmail_msg">
func readFile(_ p: String, cb: @escaping (Data)->Void)<br class="gmail_msg">
<br class="gmail_msg">
Would be trivial with a #define in C, but due to the excellence of Swift, this is not that easy to do w/o copying large amounts of code ;-> (apart from always doing @escaping and live with copying the stack to the heap, adding ARC etc, which is plain lame).<br class="gmail_msg">
<br class="gmail_msg">
Plus the error reporting issue (throws vs (error, result)).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> So I'd argue we should only have an async API for the HTTP stuff this group proposes.<br class="gmail_msg">
<br class="gmail_msg">
That sounds OK to *me*. If people want to do other stuff, they still can (libmill and such), it will just perform worse ...<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
</blockquote></div></div>