<font size=2 face="sans-serif">Hi Logan:</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">I see this as a very iterative process
- what we chose for our starting point may not be where we end up.</font>
<br>
<br><font size=2 face="sans-serif">Chris<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Logan Wright <logan@qutheory.io></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Chris Bailey/UK/IBM@IBMGB,
Tanner Nelson <tanner@qutheory.io></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">swift-server-dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">27/03/2017 15:41</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
Next HTTP API meeting</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Thanks Michael,<br>
<br>
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.</font>
<br><font size=3><br>
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.<br>
<br>
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.<br>
<br>
- Logan</font>
<br>
<br><font size=3>On Mon, Mar 27, 2017 at 3:38 PM Chris Bailey via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br><font size=2 face="sans-serif">Nice work!</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
How hard would it be to add a dispatch queue in?</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Chris</font><font size=3> <br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">Tanner
Nelson via swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=1 color=blue face="sans-serif"><u>swift-server-dev@swift.org</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">Michael
Chiu <</font><a href=mailto:hatsuneyuji@icloud.com target=_blank><font size=1 color=blue face="sans-serif"><u>hatsuneyuji@icloud.com</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Cc: </font><font size=1 face="sans-serif">swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=1 color=blue face="sans-serif"><u>swift-server-dev@swift.org</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">27/03/2017
14:38</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Re:
[swift-server-dev] Next HTTP API meeting</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><a href="mailto:swift-server-dev-bounces@swift.org" target=_blank><font size=1 color=blue face="sans-serif"><u>swift-server-dev-bounces@swift.org</u></font></a><font size=3>
<br>
</font>
<hr noshade><font size=3><br>
<br>
<br>
Re: performance, <br>
<br>
I did a quick test of inout struct vs. class performance. The code can
be found here: </font><a href="https://github.com/tanner0101/request-types" target=_blank><font size=3 color=blue><u>https://github.com/tanner0101/request-types</u></font></a><font size=3>
<br>
<br>
I found only a marginal increase in performance (~5%) in favor of inout
value types. </font><a href="https://github.com/tanner0101/request-types/issues/1" target=_blank><font size=3 color=blue><u>https://github.com/tanner0101/request-types/issues/1</u></font></a><font size=3>
<br>
<br>
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`) <br>
<br>
Please feel free to submit any prs/issues/comments about ways I could improve
this test to make it more accurate. <br>
<br>
tl;dr: value types don't seem much faster than reference types (especially
considering dangers of misuse) in a simulated web framework scenario <br>
<br>
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.
<br>
</font><font size=3 color=#9f9fe0><br>
Va</font><font size=3 color=#b1b1d2>p</font><font size=3 color=#c0c0c0>o</font><font size=3 color=#bfbfbf>r</font><font size=3 color=#9f9fe0>
</font><font size=3 color=blue><u><br>
</u></font><a href=mailto:tanner@vapor.codes target=_blank><font size=3 color=blue><u>tanner@vapor.codes</u></font></a><font size=3>
<br>
<br>
On Mar 27, 2017, at 1:55 PM, Michael Chiu via swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote: <br>
<br>
<br>
On Mar 27, 2017, at 5:13 AM, Logan Wright via swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:<br>
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. <br>
<br>
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)<br>
<br>
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:<br>
<br>
- Greatly increased bug levels and confusion related to unexpected mutation<br>
- Unnecessary code requirements added to every single passive access (ie:
middleware) increasing code bloat unnecessarily<br>
- Extreme performance loss due to massive copy overhead<br>
<br>
Each of these problems evaporated pretty instantaneously when moving to
reference types; it made it significantly easier to reason about for end
users. <br>
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. <br>
<br>
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. <br>
That’s so true lol.<br>
<br>
Michael.<br>
<br>
_______________________________________________<br>
swift-server-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target=_blank><font size=3 color=blue><u>https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></a><font size=3>
</font><tt><font size=2><br>
_______________________________________________<br>
swift-server-dev mailing list</font></tt><tt><font size=2 color=blue><u><br>
</u></font></tt><a href="mailto:swift-server-dev@swift.org" target=_blank><tt><font size=2 color=blue><u>swift-server-dev@swift.org</u></font></tt></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target=_blank><tt><font size=2 color=blue><u>https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></tt></a><font size=3><br>
<br>
</font><font size=2 face="sans-serif"><br>
<br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</font><font size=3><br>
_______________________________________________<br>
swift-server-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target=_blank><font size=3 color=blue><u>https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></a>
<br>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>