[swift-server-dev] Next HTTP API meeting

[Logan Wright]

Ben and others,

One thing I'd like to address first is middleware. People keep bringing it
up, and I see this as absolutely something that the serverside group has no
responsibility in creating or defining paradigms for. The focus of this
group should be lower and allow frameworks to define how their middleware
should be defined and act. Let's remember that many frameworks exist
because there are many ideas on how a framework should look, for now, let's
focus on parsing and serializing http. There's no reason to add additional
responsibilities to a group already in disagreement.

On protocols, if this was a private project, I'd say yes, let's use
something concrete and move to protocols when there are multiple use cases.
In this case it's not, it's a library, and there are already multiple use
cases. It is intended to be consumed by multiple different
consumers/frameworks immediately. Already we have multiple stakeholders in
the group with very different ideas and use cases for the model,
protocolizing this would allow us to focus on parsing and let frameworks
choose how to model. By opting for generics constrained to our protocol
internally, the compiler will inline the code and give us pretty good
performance, in our generic constrained code, it was just as fast, or
faster than it's model counterparts.

Here's an example of a protocol required to parse a request

```
protocol HTTPMessage {
    init(status: String, version: String, method: String, headers: [String:
String], etc...
}
```

It doesn't need to be anything particularly complex, and we could include
easily the inverse as well for the serializer. This could be a distinct
protocol even for use cases we might not consider.

I'd like to just put up a quick reminder that we're not building a
framework here, we're building core apis that are intended to be flexible
and useful for framework developers. With something like this, we could
easily conform foundation's URLRequest or NSURLRequest by default so basic
users could use those built in without much effort, but framework
developers wouldn't be stuck constantly dealing with non-native objects or
doing unnecessary conversions.

This doesn't take away from anything that has been proposed so far, and
creates additional capabilities and flexibilities for a system that is
intended to be just that ... flexible. In general, I think it's important
for us to remind ourselves what we're building and that creating the most
flexible possible code will make the library more lasting and allow users
to create unique and interesting interactions that we might not have even
considered in our narrow scope. We want to support and encourage this
creativity, not stifle it, wherever possible. Looking forward to working
through more of this.

- Logan

On Wed, Mar 22, 2017 at 6:41 PM Swizzlr via swift-server-dev <
swift-server-dev at swift.org> wrote:

> 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
>
> _______________________________________________
> 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/20170323/352d3e48/attachment.html>