[swift-server-dev] Next HTTP API meeting

Helge Heß me at helgehess.eu
Tue Mar 28 16:12:19 CDT 2017

On Mar 28, 2017, at 12:07 PM, Michael Chiu via swift-server-dev <swift-server-dev at swift.org> wrote:
> I think we’re going around circles in the mailing list on type vs semantic.

Well said.

The opinions stated are *super* diverse. ARC object vs. value vs. inout ref vs. UnsafePointer. Mutable vs. immutable. Protocol or not. Closed enums for methods and headers, or strings, or Ints? Typed header values or not?

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.

Which brings me back to my original mail which started the thread:

> On Mar 20, 2017, at 9:05 PM, Helge Hess <helge.hess at icloud.com> wrote:
>> I wonder where this is going. I mean all those discussions are nice and valuable, but someone eventually has to do the work, right? :-)
>> My understanding is that there is a goal to have that essentially ready in summer / for Swift 4, right? How is this going to happen? Is IBM and/or Apple going to provide a reference implementation and the others can use it or not?

IMO the whole email thread didn’t bring us forward much, it was just a continuation of the discussion which just showed again that pretty much everyone has a different opinion on how stuff should work (mine being the only correct one).
Some had hope that maybe protocols could abstract away the differences, but then even the use of protocols seems controversial :-)

On Mar 20, 2017, at 11:11 PM, Logan Wright <logan at qutheory.io> wrote:
> if there's a chance that they can all find common ground, then it must be pursued

Quite honestly it doesn’t look to me like there is a chance for that?

Any ideas on how this may go forward? IBM/Apple decide and provide a reference implementation of SSS, others may adopt/wrap or not? :-)


More information about the swift-server-dev mailing list