I agree HTTP/2 support should come in the first iteration of this package. <br><br>In terms of timing, though, is it possible to come to a consensus on an HTTP/1.1 API first and then add HTTP/2? In other words, are the features additive? Or is it pertinent HTTP/2 is a part of the design process for HTTP/1.1 support? (I'm not as familiar with HTTP/2 as I probably should be :))<br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 14, 2017 at 12:24 Michael Chiu via swift-server-dev <<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think server side swift has the advantage being a young server-side option and HTTP/2 is basically a must (For example, APNS support only HTTP/2 request).<br>
<br>
On the other hand, a full HTTP/2 is pretty hard to implement due to it's layer violation design, hence we probably can’t even work on it before having a solid implementation of stream api.<br>
<br>
I don’t think it relate to the matter of swift concurrency api tho, but how we manage different connections (probably on the stream level).<br>
<br>
Michael.<br>
<br>
<br>
> On Jun 14, 2017, at 4:10 AM, Rien via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br>
><br>
> According to wikipedia, market penetration is about 14% for HTTP/2 servers.<br>
><br>
> Though not necessarily so, it does seem to me that HTTP/2 and a native swift concurrency model might go hand in hand?<br>
><br>
> I.e. does it make sense to talk about HTTP/2 support without a native Swift concurrency API?<br>
><br>
> Regards,<br>
> Rien<br>
><br>
> Site: <a href="http://balancingrock.nl" rel="noreferrer" target="_blank">http://balancingrock.nl</a><br>
> Blog: <a href="http://swiftrien.blogspot.com" rel="noreferrer" target="_blank">http://swiftrien.blogspot.com</a><br>
> Github: <a href="http://github.com/Balancingrock" rel="noreferrer" target="_blank">http://github.com/Balancingrock</a><br>
> Project: <a href="http://swiftfire.nl" rel="noreferrer" target="_blank">http://swiftfire.nl</a> - An HTTP(S) web server framework in Swift<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
>> On 14 Jun 2017, at 12:16, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> one important thing I miss in the current proposal is support for the new HTTP/2 features, primarily server push and priorities. We don’t want to design for the past, right? :-><br>
>><br>
>> I have no specific proposal on how to do them, but it feels like they should be fully interoperable w/ the older versions (if you set either, they just get ignored in those setups, or maybe are converted to an x- header).<br>
>><br>
>> hh<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br>
</blockquote></div>