[swift-server-dev] Next HTTP API meeting

[Helge Heß]

On Mar 28, 2017, at 2:32 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> On Mar 27, 2017, at 1:55 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
>> 
>> Primarily this lacks an implementation of a CoW backed value type which could avoid thread safe RC and hence be significantly faster.
> 
> I've got a PR for one of those, as well as for non-`inout` argument passing: <https://github.com/tanner0101/request-types/pull/2>

"A HybridRequest is a struct with a private nested class”

That way you have the overhead of ARC *and* a struct :-) Well if your struct is just the pointer, so why not use the class in the first place? Just to get copy behavior which I don’t think played a huge role in the discussion (well, someone even claimed non-copy behavior actually reduces bugs ;-)

I was thinking more along the lines of using UnsafePointer with an own (unprotected) retain count. Not sure whether that is even possible in Swift. (the idea being that the RC of a request isn’t modified by multiple threads ever).


> Is the use of `inout` here purely a performance hack, or is it semantically significant?

That depends on the higher level framework. Some store values (like a restored session) in the request, others may use secondary objects for that.

> That is, are you *supposed* to write into the request in ways that middlewares above you will see?

You mean below in the sequence? Yes. This is what Node does. E.g. middleware could parse Basic Auth and store a REMOTE_USER variable into the request. Or parse a session cookie, retrieve that and then attach the session to the request.

It is questionable whether this is actually a good design, but this is what Node does and people are accustomed to. Hence some implement it that way.

> If so, I question whether that's a good idea—it seems to me that communication back up the stack should be through the response, not the request.

Something a web framework needs to decide. Personally I prefer the WebObjects setup where the request is just the request and the response is just the response, and all framework state is attached to a separate context.

hh