[swift-server-dev] Next HTTP API meeting

[Swizzlr]

I think protocols by their self evident definition of an interface only will allow the HTTP library implementors to provide a consistent and stable interface that we can internally reimplement (for instance, upgrade). In the face of ABI stability and resilience, protocols are going to live longest, I would think.

On the subject of middlewares, let's remember that one framework's middleware is another's shared data nightmare. I would fully expect many frameworks to wrap the raw HTTP requests or response streams in opinionated APIs of their own design.

Tom

Sent from my iPhone

> On 22 Mar 2017, at 13:55, Paulo Faria via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> > Protocols in Swift exist primarily to allow code to operate on multiple different concrete implementations simultaneously – either with generics as constraints, or as existentials. In this case, there is no clear reason why someone would want to write code that handles two separate implementations of an HTTP API at the same time within a single program.
> 
> I completely agree with this. Using protocols to allow multiple implementations in this scenario would not be a solution for a technical problem. It would be, instead, a solution for a "human" problem which is basically the difficulty of reaching an agreement. In the end what we all want is the best solution technically.
> 
>>> On 22 March 2017 at 10:19, Ben Cohen via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> 
>>> On Mar 20, 2017, at 11:11 PM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> 
>>> I'd personally like to see us more explicitly explore protocols, I haven't seen anything so far that actually requires a concrete model and would perhaps be an easier way for us to reach consensus.
>> 
>> Hi Logan,
>> 
>> What is it about protocols that you feel would help here? In general, the relationship between concrete implementations and protocols should be that the former comes first, then the latter. Start with a concrete type, then as you move to multiple diverse implementations, factor out the common things that unify those types.
>> 
>> Protocols in Swift exist primarily to allow code to operate on multiple different concrete implementations simultaneously – either with generics as constraints, or as existentials. In this case, there is no clear reason why someone would want to write code that handles two separate implementations of an HTTP API at the same time within a single program. Protocols are not necessary in order to “swap” implementation A for implementation B. All that is needed for this is that the two implementations be source compatible i.e. have the same method signatures (protocols are a way of helping enforce that, but there are other less performance-consequential ways of doing it too).
>> 
>> Now, it may be that a need does emerge as the design takes shape to have separate types, say, for different kinds of HTTP connections, that might need to be handled by the same program and have to be unified via a protocol to enable handling code to be shared across both. But this protocol should be discovered through the process of looking at the common features the different concrete types have, rather than designed up front.
>> 
>> Cheers,
>> Ben
>> 
>> 
>> 
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-server-dev
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170322/7f5b52a7/attachment.html>