[swift-server-dev] Next HTTP API meeting

[Paulo Faria]

I'm with Brent a 100%. As discussed before in Open Swift, the embryo that
lead to the Swift Server APIs Work Group, using a protocol for the HTTP
request/response is not the best option because of the value type/reference
type duality. People implementing an HTTP middleware, for example, would
have to decide themselves which type semantics they're expecting the
underlying implementation to provide. This means that code written with one
semantics in mind would present bugs if used with an implementation that
uses the other implementation. Of course we could restrict the protocol to
reference types by making it a class protocol, but if we're doing that we
might as well just go with classes. So the best solution is to go with
concrete types. I prefer value type semantics, and to be honest, after
reading the memory ownership manifesto, maybe move semantics would be the
best option for HTTP request/response, but since we don't have it yet, I
think we should go with value types for now.

On Mon, Mar 27, 2017, 07:40 Brent Royal-Gordon <brent at architechies.com>
wrote:

> On Mar 23, 2017, at 2:51 AM, Logan Wright via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
> 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.
>
>
> Okay, but one of the major complaints I see in the GitHub thread is that
> some people want to use a reference type, and it seems like some people may
> want protocols so they can make that decision for themselves. I don't think
> that's going to work, though. If the protocol has any setters or mutating
> methods, then it will need to document whether it expects value or
> reference semantics; otherwise nobody will be able to know how to use those
> members properly.
>
> (Also, if that really is the entire `HTTPMessage` protocol—just an
> initializer—why not have users pass in a closure with that signature
> instead? They could easily pass `MyFramework.HTTPMessage.init` if they
> want, but they would have other choices too.)
>
> As for the performance aspect of value types, I don't quite see the
> concern. If we find that performance is a problem, we can switch to a
> copy-on-write implementation, where a public struct wraps a private class
> which actually contains the data; that should be exactly equivalent for ARC
> purposes. Choose value or reference based on the semantics you want; if the
> performance characteristics are wrong, you can then begin to optimize.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/e1659d85/attachment.html>