[swift-server-dev] Next HTTP API meeting

Mon Mar 27 11:12:40 CDT 2017

Hi Logan:

One of the key goals is to provide the concrete implementation of a 
utility library for HTTP parsing, rather than a protocol definition for an 
API. This means that we need (broad) consensus on what that implementation 
will look like - at least for first pass prototype. We'll then need to 
validate and refine based on feedback - which includes trying to plug it 
into existing frameworks.

I see this as a very iterative process - what we chose for our starting 
point may not be where we end up.

Chris

From:   Logan Wright <logan at qutheory.io>
To:     Chris Bailey/UK/IBM at IBMGB, Tanner Nelson <tanner at qutheory.io>
Cc:     swift-server-dev <swift-server-dev at swift.org>
Date:   27/03/2017 15:41
Subject:        Re: [swift-server-dev] Next HTTP API meeting

Thanks Michael,

Those are good examples, just for records as people read along, the 
reference alternative to these would be a non static value that is 
constructed each time. To end user, it would be the same, with the 
difference that the code is computed each time, so possibly a minor 
performance hit if construction time > copy time.

I completely agree, I think protocols are the most flexible way to 
implement the apis, I also believe that they're most in the spirit of the 
group which is to create something adaptable to the various frameworks to 
allow more code share for low level libraries. I haven't seen anything yet 
that couldn't be accomplished with protocols and leave end implementations 
up to consumers. This would allow us to really focus on the abstract 
values returned by the parser and let the group move forward with the onus 
of models on end users.

I think it's worth outlining some of the result of a parser in abstract 
values, for example. The most basic HTTP Header based on our discussions 
would be `[(String, String)]`, the most basic method would be `String`, 
etc. Then we could see how a protocol based model would fit this. If we 
can come up with some agreements there, generics and inlining could create 
some pretty performant code without infringing on the creativity of 
various frameworks.

- Logan

On Mon, Mar 27, 2017 at 3:38 PM Chris Bailey via swift-server-dev <
swift-server-dev at swift.org> wrote:
Nice work! 

Taking a quick look at the project and screenshot, am I right in saying 
that there is no concurrency in the test? ARC generally has a bigger 
impact in concurrent use cases because of the need to keep memory 
consistency across processors for the atomic increment/decrement. 

How hard would it be to add a dispatch queue in? 

Chris 

From:        Tanner Nelson via swift-server-dev <
swift-server-dev at swift.org> 
To:        Michael Chiu <hatsuneyuji at icloud.com> 
Cc:        swift-server-dev <swift-server-dev at swift.org> 
Date:        27/03/2017 14:38 
Subject:        Re: [swift-server-dev] Next HTTP API meeting 
Sent by:        swift-server-dev-bounces at swift.org 

Re: performance, 

I did a quick test of inout struct vs. class performance. The code can be 
found here: https://github.com/tanner0101/request-types 

I found only a marginal increase in performance (~5%) in favor of inout 
value types. https://github.com/tanner0101/request-types/issues/1 

Additionally, non-inout value types were a lot slower. This is obvious to 
the seasoned Swift dev considering each middleware in the test modifies 
and thus must copy the request. But this is the exact type of performance 
issue you can expect developers to create when interacting with 
"non-obvious value types". HTTP request/response being non-obvious value 
types compared to something like an integer or a float. (I'd argue the 
majority of web developers would expect request/response to be a reference 
type and thus easily forget or not know to use `inout`) 

Please feel free to submit any prs/issues/comments about ways I could 
improve this test to make it more accurate. 

tl;dr: value types don't seem much faster than reference types (especially 
considering dangers of misuse) in a simulated web framework scenario 

inb4: people saying that the request/response models in my test are 
incomplete/not fully implemented/bad. this is _not_ a proposed api for 
request/response. 

Vapor 
tanner at vapor.codes 

On Mar 27, 2017, at 1:55 PM, Michael Chiu via swift-server-dev <
swift-server-dev at swift.org> wrote: 

On Mar 27, 2017, at 5:13 AM, Logan Wright via swift-server-dev <
swift-server-dev at swift.org> wrote:
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. 

I disagree with this one. First of all I think most of the framework pass 
the request and response as inout argument, if that is the case there 
shouldn’t be much copy overhead in the run loop. Second the problem of 
reference type is that everywhere the request and response exists could 
possibly mutate the res/req, and it affect globally. It is true that in 
normal use there shouldn’t be two place simultaneously operate on the same 
request but that could happen. (Therefore protocol is the best isn’t it)

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. 
Just for curiosity, I’m very interested in the unexpected mutation of 
value semantic, I have always had an impression of value semantic are more 
free from unexpected mutation. 

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. 
That’s so true lol.

Michael.

_______________________________________________
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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/5df00143/attachment.html>