<div dir="ltr">> _What model are we going to use? Should request/response be value types or reference types?_<br><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">> * At the lowest level, we’ll just be providing bytes - the framework can deal with the contents?</div><div><br></div><div>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.</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 23, 2016 at 2:57 AM, Chris Bailey via swift-server-dev <span dir="ltr"><<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font size="2" face="sans-serif">The minutes from Monday's HTTP kick-off
meeting are now available for review/comment here:</font>
<br><font size="2" face="sans-serif"> </font><a href="https://github.com/swift-server/work-group/pull/52" target="_blank"><font size="2" color="blue" face="sans-serif">https://github.com/swift-serve<wbr>r/work-group/pull/52</font></a>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br>
<br><font size="2" face="sans-serif">Chris<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><br>______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-server-dev</a><br>
<br></blockquote></div><br></div></div>