[swift-server-dev] Next HTTP API meeting

[Logan Wright]

As far as this suggestion:


*(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.)*
I am 100% for anything that abstracts models and concrete implementations
further down the road to end users. This falls in line with that, and could
be a nice flexible way to allow end users more creativity.

Logan

On Mon, Mar 27, 2017 at 1:13 PM Logan Wright <logan at qutheory.io> wrote:

> Hey Everyone,
>
> I disagree with the premise that protocols inherently create bugs, but
> would be open to constraining to classes if this alleviates concerns. If we
> create protocols, this allows frameworks to implement concrete models with
> whatever semantics they see fit. Any subsequent interaction from the
> framework would have a concrete type to rely on.
>
> In terms of what we're building here, I don't see middleware as much of a
> responsibility since this should be the tools that a framework would use. I
> think it's very important for all of us to remember that we're not building
> a web framework. We're building the tooling to make a good starting point
> for others to use in development of a web framework.
>
> If people feel extremely strong that there needs to be a concrete type,
> then I'd like to push for reference type as much as possible. As far as
> reference vs value type, I haven't really heard an argument for value types
> beyond what feels like a reaction to value types being the hip new hotness.
> While yes, they're great in Swift, and there's tons of places that should
> absolutely be modeled with value semantics, a request/response interaction
> represents a single request and should definitely be a reference based
> interaction.
>
> In practice, we went through several model iterations and the value type
> created very high levels of bugs and confusion for end users. The three
> biggest problems we had were as follows:
>
> - Greatly increased bug levels and confusion related to unexpected mutation
> - Unnecessary code requirements added to every single passive access (ie:
> middleware) increasing code bloat unnecessarily
> - Extreme performance loss due to massive copy overhead
>
> Each of these problems evaporated pretty instantaneously when moving to
> reference types; it made it significantly easier to reason about for end
> users.
>
> Summary:
>
> Would like to remind again for those that skipped above reading that our
> goal is not to build a web framework here, but rather to build small tools
> that make building frameworks slightly easier for library maintainers and
> creators.
>
> Ideally, we could abstract the memory semantics away and leave them up to
> frameworks by utilizing protocols .. this is my preference. If however,
> concrete models are required, I feel reference type is the ideal choice for
> the reasons outlined above. I believe that a request/response interaction
> is representative of singular instances that should be referenced by
> various interactors as opposed to introducing more copy/mutation complexity
> and a model that doesn't fit with the concept.
>
> Looking forward to more discussion, thanks for participating everyone!
>
>
> Logan
>
> On Mon, Mar 27, 2017 at 12:52 PM Paulo Faria <paulo at zewo.io> wrote:
>
> 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/9ab8b28f/attachment.html>