[swift-server-dev] [HTTP] Value vs Reference Types

[Dan Appel]

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
an enum
<https://github.com/Zewo/Zewo/blob/master/Modules/HTTP/Sources/HTTP/Message/Body.swift#L1>.
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.
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
-- 
Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161123/d2ba7efc/attachment.html>