HTTP sub-team kick-off minutes


(Chris Bailey) #1

The minutes from Monday's HTTP kick-off meeting are now available for
review/comment here:
        https://github.com/swift-server/work-group/pull/52

If you've got any questions of anything you'd like to discuss from the
minutes, here on the mailing list is the best place to do that.

Chris
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


(Andrew Akira Toulouse) #2

_What model are we going to use? Should request/response be value types

or reference types?_

A couple of somewhat related thoughts: I find that handling multipart
uploads is typically awkward to handle in APIs that are built to mainly to
expect the typical POST or GET requests. It almost but doesn't quite fit
into a typical request/response paradigm, but it should be handled
efficiently even if it's just to forward the byte stream to some backend
storage service. For example, if one were to implement an internal API to
upload to S3 using their multipart API, the implementation detail of the
multipart chunks would have to be exposed, and this often goes against
frameworks which try to avoid access to persistent state (a good goal, but
contradictory nonetheless).

I also think it's hard to figure out exactly how best to make use of memory
when handling large files. A pattern I'm fond of, but haven't yet had much
time to experiment with, is holding the response data's body in memory
as-is, and using a class to smartly offset and access that inline when
performing some sort of transformation, as a strategy to reduce memory
copies. If I recall, this is the strategy FlatBuffers takes -
parseless/unpacking-less reading of memory buffers to data.

Given the much lower footprint of Swift versus Java, I expect to be running
Swift servers on VMs which are very memory-constrained, so whichever
strategy can predictably and reliably minimize memory usage sounds
preferable, whether that means using reference types or value types.

* At the lowest level, we’ll just be providing bytes - the framework can

deal with the contents?

I like the idea of being encoding-agnostic. Could always have an opt-in
bytes->UTF8 encoder step, but not everyone's going to want to operate on
text.

···

On Wed, Nov 23, 2016 at 2:57 AM, Chris Bailey via swift-server-dev < swift-server-dev@swift.org> wrote:

The minutes from Monday's HTTP kick-off meeting are now available for
review/comment here:
        https://github.com/swift-server/work-group/pull/52

If you've got any questions of anything you'd like to discuss from the
minutes, here on the mailing list is the best place to do that.

Chris
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev