[swift-server-dev] [HTTP] Value vs Reference Types
dan.appel00 at gmail.com
Wed Nov 23 17:09:21 CST 2016
I think it's important to make the distinction between performance and
semantics, but just to address this...
>Unless you are talking about just the HTTP message head (which is not much
more than a specialised dictionary), it doesn’t make any sense to me to
pass them around as values.
>The body's of the HTTP messages can be gigabytes big and won’t usually be
stored in-memory at all or at least as-is. Processing state on the body
stream needs to be passed around as a reference.
The model we chose for Zewo is to have the request store both the head and
the body. I understand that you are worried about copying around requests
with large bodies. To that, I want to remind you that Swift's preferred way
to address this is through Copy-on-Write, which is taken advantage of
automatically when using arrays.
The other point you raise is that the body may be a stream, at which point
it is impossible to copy around. What we did here for Zewo is make the body
So, if you want to return a file stream, you just do that. Copying the
message around will keep a reference to the same stream, but since its
immutable this isn't an issue.
I urge you to reconsider your stance. Just because something can be very
large doesn't immediately mean it should be a reference type.
On Wed, Nov 23, 2016 at 2:45 PM Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:
> On 23 Nov 2016, at 22:19, Dan Appel via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >> 1. Do we want to use concrete types or protocols for Request/Response?
> > When working on Open Swift, this was a hot topic since we believed that
> it would be unsafe to have a protocol that would allow both value and
> reference types.
> >> 2. If we use concrete types, do we want value or reference semantics?
> Kinda what you said before this decision is unrelated to protocol vs
> concrete type. I suppose protocols may make some sense, so that they can be
> backed by different mechanisms (say libcurl or http_parser, etc).
> E.g. quite often you don’t really need to decode all fields of an HTTP
> header but just specific fields of it, or you need the fields just once. In
> such cases it may not be necessary to proactively waste space on a hash-map
> and actual strings for such and instead just keep the buffer containing the
> data and do things on demand (aka don’t parse/load stuff you don’t use).
> All I’m saying is that there may be different implementations for
> different uses cases.
> BTW: It was also mentioned that it may be highly desirable to use
> Foundation’s NSHTTPURLRequest/NSHTTPResponse.
> > To me, it makes sense to pass them around as values
> Unless you are talking about just the HTTP message head (which is not much
> more than a specialised dictionary), it doesn’t make any sense to me to
> pass them around as values.
> The body's of the HTTP messages can be gigabytes big and won’t usually be
> stored in-memory at all or at least as-is. Processing state on the body
> stream needs to be passed around as a reference.
> swift-server-dev mailing list
> swift-server-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-server-dev