<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 12, 2016, at 5:45 AM, Samuel Kallner <<a href="mailto:KALLNER@il.ibm.com" class="">KALLNER@il.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><font size="2" face="sans-serif" class="">My biggest problem with responses being
structs is that it makes it much harder to have a server in which multiple
independent pieces of code need to run in order for the request to be processed.
Why is this useful? It's nice to have all sorts of things that "annotate"
the Request and the Response, such as Session support, Compression support,
Authentication support, and others.</font><br class=""><br class=""></div></blockquote><div><br class=""></div><div><div class="">This is an argument for operations on types to be pass-by-reference, rather than for the types themselves to be reference types. There are various different ways to handle this without resorting to reference types.</div><div class=""><br class=""></div><div class="">Swift supports this via the <font face="Menlo" class="">inout</font> keyword. It isn’t quite pass-by-reference (see <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID545" class="">TSPL</a> for details) but it is similar enough for our purposes here from a performance/usage perspective. It also forces the caller to acknowledge the mutation by adding the <font face="Menlo" class="">&</font> sigil at the call site, helping with the problem Dan outlined where a user can be surprised by a function mutating its argument.</div></div><div><br class=""></div><div><div class="">If appropriate, you can also add mutating methods as extensions e.g. <font face="Menlo" class="">request.compress()</font>. You can think of this as like passing <font face="Menlo" class="">self inout</font>. Indication of mutation here should be via appropriate naming of the method.</div><div class=""><br class=""></div><div class="">There are also more elaborate techniques, such as wrapping adapters that maybe perform tasks lazily. For example <font face="Menlo" class="">myArray.reversed() </font>doesn’t actually reverse an array, it just wraps the array in a <font face="Menlo" class="">ReversedCollection</font> “view” that presents the data in a reversed fashion. This is a lot more complicated, and is only a win if it significantly improves the user experience for both readability and performance, but when it works, it can be a big win. </div></div><br class=""><blockquote type="cite" class=""><div class=""><font size="2" face="sans-serif" class="">If one's handlers, as in the example
in Ben's e-mail are designed to simply return a Response struct, the only
way subsequent handlers can modify the response is by wrapping the call
to the next handler in the chain, creating a new response based on the
response received, and returning this new response.</font><br class=""><br class=""><font size="2" face="sans-serif" class="">This causes one of two things. </font><br class=""><br class=""><font size="2" face="sans-serif" class=""> 1. There are two types
of handlers, one type that simply gets invoked and returns a Response struct
and a second type that gets a</font><br class=""><font size="2" face="sans-serif" class=""> chain to
invoke the next handler in the chain.</font><br class=""><font size="2" face="sans-serif" class=""> 2. The nice and clean
API in the example needs to be changed. And one always needs to deal with
the results of the chain......</font><br class=""><br class=""><font size="2" face="sans-serif" class="">The problem I have is that it seems
to be a very artificial need for two different types of handlers. You also
then need an opinionated definition of when each kind of handler runs.</font><br class=""><br class=""></div></blockquote><div><br class=""></div><div>Bear in mind with value types, it is straightforward to implement the return-a-fresh-value implementation in terms of the mutate-in-place one. The mutating/non-mutating pair pattern is adopted widely, is covered in the API naming guidelines, and its implications are well understood by the community. So the definition of when each kind of handler is needed should be clear.</div><br class=""><blockquote type="cite" class=""><div class=""><font size="2" face="sans-serif" class="">To me things become much simpler if
there is a chain of handlers that need to be run, with simple straight
forward order. To do that I believe Both the Request and the Response need
to be reference types.</font><br class=""><br class=""></div></blockquote><div><br class=""></div><div>This argument in favor of reference types and against the value-type approach does not to me seem like it’s specific to this particular use case. It is common to perform chains of operations on arrays, for example. The need to implement these operations efficiently is what leads to both the in-place/new-value method pair approach, as well as techniques such as .<font face="Menlo" class="">lazy</font>. But the clarity/correctness benefits of value types are remain and are an important aspect of the Swift style of programming.</div><div><br class=""></div><div>Not adopting these techniques would put the style of this library at odds with the other core Swift libraries from a style perspective, something that I feel would be very hard to defend when considering this library for adoption by the community as a standard.</div><br class=""><blockquote type="cite" class=""><div class=""><font size="2" face="sans-serif" class="">Shmuel Kallner</font><br class=""><font size="2" face="sans-serif" class="">STSM Smart Client Platforms group<br class="">Tel: +972-4829-6430<br class="">e-mail: <a href="mailto:kallner@il.ibm.com" class="">kallner@il.ibm.com</a></font><br class=""><br class=""><br class=""><br class=""><br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">From:
</font><font size="1" face="sans-serif" class="">Chris Bailey via swift-server-dev
<<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>></font><br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">To:
</font><font size="1" face="sans-serif" class="">Ben Cohen <<a href="mailto:ben_cohen@apple.com" class="">ben_cohen@apple.com</a>></font><br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Cc:
</font><font size="1" face="sans-serif" class="">"<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>"
<<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>></font><br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Date:
</font><font size="1" face="sans-serif" class="">12/12/2016 14:11</font><br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Subject:
</font><font size="1" face="sans-serif" class="">Re: [swift-server-dev]
[HTTP] Value vs Reference Types</font><br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Sent by:
</font><font size="1" face="sans-serif" class=""><a href="mailto:swift-server-dev-bounces@swift.org" class="">swift-server-dev-bounces@swift.org</a></font><br class=""><hr noshade="" class=""><br class=""><br class=""><br class=""><font size="2" face="sans-serif" class="">Thanks Ben. This is really useful.</font><font size="3" class=""><br class=""></font><font size="2" face="sans-serif" class=""><br class="">Its probably worth also adding some information on the approach taken by
Foundation today for URLRequest/Response. </font><font size="3" class=""><br class=""></font><font size="2" face="sans-serif" class=""><br class="">For outbound requests, Foundation provides both NSURLRequest (class) and
URLRequest (struct). In the case of URLRequest (struct), there is a mix
of types as it contains a getter that returns a stream class for the body
- and the with a number of warnings commented in the code:</font><font size="3" class=""></font><font size="2" face="sans-serif" class=""><br class=""> <i class="">"The stream is returned for examination
only; it is not safe for the caller to manipulate the stream in any way"</i></font><font size="3" class=""></font><font size="2" face="sans-serif" class=""><br class="">(</font><a href="https://github.com/apple/swift-corelibs-foundation/blob/5ab46791996cb65079d02f98115cef6562d4819b/Foundation/URLRequest.swift#L187" class=""><font size="2" color="blue" face="sans-serif" class=""><u class="">https://github.com/apple/swift-corelibs-foundation/blob/5ab46791996cb65079d02f98115cef6562d4819b/Foundation/URLRequest.swift#L187</u></font></a><font size="2" face="sans-serif" class="">)</font><font size="3" class=""></font><font size="2" face="sans-serif" class=""><br class="">This is presumably because you shouldn't need to modify the stream for
an outbound request</font><font size="3" class=""> <br class=""></font><font size="2" face="sans-serif" class=""><br class="">For responses from outbound requests, only NSURLResponse (class) is provided
as the body is read from the stream.</font><font size="3" class=""> <br class=""></font><font size="2" face="sans-serif" class=""><br class="">This effectively give us a model where:</font><font size="3" class=""> </font><font size="2" face="sans-serif" class=""><br class=""> outbound can be
a struct (you shouldn't need to touch the stream)</font><font size="3" class=""> </font><font size="2" face="sans-serif" class=""><br class=""> inbound class (reading
from stream)</font><font size="3" class=""> </font><font size="2" face="sans-serif" class=""><br class="">For the server case, we need the mirror opposite of this - with incoming
requests being a class and the outgoing response potentially being a struct.
</font><font size="3" class=""><br class=""></font><font size="2" face="sans-serif" class=""><br class="">This leads to two questions:</font><font size="3" class=""> </font><font size="2" face="sans-serif" class=""><br class="">1. Do we think the Foundation model is correct?</font><font size="3" class=""> </font><font size="2" face="sans-serif" class=""><br class="">2. Do we think it would be confusing to switch been classes and structs
when working with inbound vs. outbound requests, or do we think it would
enforce correct behaviour?</font><font size="3" class=""> <br class=""></font><font size="2" face="sans-serif" class=""><br class="">Chris</font><font size="3" class=""><br class=""><br class=""><br class=""><br class=""></font><font size="1" color="#5f5f5f" face="sans-serif" class=""><br class="">From: </font><font size="1" face="sans-serif" class="">Ben
Cohen via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>></font><font size="3" class=""></font><font size="1" color="#5f5f5f" face="sans-serif" class=""><br class="">To: </font><font size="1" face="sans-serif" class="">Dan
Appel <<a href="mailto:dan.appel00@gmail.com" class="">dan.appel00@gmail.com</a>></font><font size="3" class=""> </font><font size="1" color="#5f5f5f" face="sans-serif" class=""><br class="">Cc: </font><font size="1" face="sans-serif" class="">"<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>"
<<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>></font><font size="3" class=""> </font><font size="1" color="#5f5f5f" face="sans-serif" class=""><br class="">Date: </font><font size="1" face="sans-serif" class="">08/12/2016
02:04</font><font size="3" class=""> </font><font size="1" color="#5f5f5f" face="sans-serif" class=""><br class="">Subject: </font><font size="1" face="sans-serif" class="">Re:
[swift-server-dev] [HTTP] Value vs Reference Types</font><font size="3" class=""></font><font size="1" color="#5f5f5f" face="sans-serif" class=""><br class="">Sent by: </font><font size="1" face="sans-serif" class=""><a href="mailto:swift-server-dev-bounces@swift.org" class="">swift-server-dev-bounces@swift.org</a></font><font size="3" class=""><br class=""></font><hr noshade="" class=""><font size="3" class=""><br class=""><br class=""><br class="">Hi Dan, <br class=""><br class="">Thanks for spelling out these questions, I think they are a great starting
point for a discussion. A few comments inline. <br class=""><br class="">On Nov 23, 2016, at 1:19 PM, Dan Appel via swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" class="">>
wrote: <br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">My own responses:</font><font size="3" class=""> <br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">>1. Do we want to use concrete types or protocols for Request/Response?</font><font size="3" class=""><br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">When working on </font><a href="https://github.com/open-swift" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">Open
Swift</u></font></a><font size="1" face="Helvetica" class="">, 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. </font><font size="3" class=""><br class=""><br class="">Bear in mind that a protocol is more than just the methods and types it
declares – it is also its documentation. For example, a number of protocols
in the standard library state things like complexity requirements in their
documenting comments. The language has no way of enforcing these, but your
type does not truly “conform” to the protocol unless you adhere to them.
Value semantics are similar – you can document that it is invalid to implement
a protocol with reference semantics. So I don’t think this is a blocker
to wanting to use protocols. <br class=""></font><font size="1" face="Helvetica" class=""><br class="">We arrived upon the `{Request|Response}Representable` pattern which worked
but was a bit of a mess. Because of this, I would prefer concrete Request/Response
types.</font><font size="3" class=""> <br class=""><br class=""><br class="">You could think of there as being 3 purposes to using protocols here, roughly
in order of importance: </font><ul class=""><li class=""><font size="3" class="">being able to write generic code </font></li><li class=""><font size="3" class="">allowing different frameworks to interoperate </font></li><li class=""><font size="3" class="">documenting what you need to implement</font></li></ul><font size="3" class=""><br class="">The first one is the only reason why a protocol must be included in a library,
and the key question to ask when considering defining a protocol like this
is “What common algorithms do you want to write across multiple different
conforming types in your program”? (such as generic functions, including
protocol extensions, or functions that take an existential if the protocol
has no associated types). <br class=""><br class="">This is distinct from wanting to be able to be able to choose from different
library implementations of Request. You might want to choose between the
Acme Inc Web Framework’s Request type, or some Swift-Server “official"
Request type, but you never need to use both at once and write code spanning
them. You just want to make sure that one can serve as a source-compatible
“drop-in” replacement for the other in your code. This doesn’t mean
you can’t write your own extensions – but you would extend the concrete
Request not a RequestRepresentable protocol. <br class=""><br class="">Next, it’s possible that there might be a collection of 3rd-party frameworks
out there that don’t define Request, but want to be able to write methods
that take or extend multiple possible Request implementations. This seems
a bit unlikely in the case of these types, more likely in other cases like
networking, so it’s kind of a what-if scenario where there are both multiple
popular implementations of Request, and various frameworks that want to
interact with them. Anyone can add a conformance to anything, so those
frameworks can define a protocol of their own with a subset of the functionality
they need, and then just extend the popular implementations to conform
to it. If this gets really common, at that point it might be worth creating
an official protocol for everyone to share – but this can be done later,
doesn’t have to be done up-front. <br class=""><br class="">Finally, if you do expect multiple implementations and want people to be
able to swap them in and out when they choose, the protocol can serve to
document what methods and properties you are expected to implement to be
“source compatible". This can be done in documentation instead, the
benefit of the protocol being it helps the library developer ensure they’ve
got all the signatures right etc. But this isn’t something you expose
to users, it’s something on the side to help implementors. <br class=""><br class="">Based on all the above, it seems like there isn’t a pressing need for
a protocol for these types right now and initial designs should focus on
a concrete implementation until one emerges, if only to avoid premature
generalization. Useful protocols tend to be discovered, rather than designed,
through a desire to share common operations on different concrete types.
<br class=""></font><font size="1" face="Helvetica" class=""><br class="">>2. If we use concrete types, do we want value or reference semantics?</font><font size="3" class=""><br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">What I think makes this easier is that the "big four" have each
taken a slightly different approach that can be used as a reference.</font><font size="3" class=""></font><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://github.com/Zewo/Zewo/blob/master/Modules/HTTP/Sources/HTTP/Message/Request.swift#L3" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">Zewo</u></font></a><font size="1" face="Helvetica" class="">- struct, value semantics</font><font size="3" class=""> </font><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://github.com/vapor/engine/blob/master/Sources/HTTP/Models/Request/Request.swift#L4" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">Vapor</u></font></a><font size="1" face="Helvetica" class="">- closed class, reference semantics</font><font size="3" class=""> </font><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://github.com/IBM-Swift/Kitura/blob/master/Sources/Kitura/RouterRequest.swift#L26" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">Kitura</u></font></a><font size="1" face="Helvetica" class="">- closed class + has-a pattern, reference semantics</font><font size="3" class=""></font><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://github.com/PerfectlySoft/Perfect-HTTP/blob/master/Sources/HTTPRequest.swift#L25" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">Perfect</u></font></a><font size="1" face="Helvetica" class="">- class protocol, reference semantics</font><font size="3" class=""> <br class=""></font><font size="1" face="Helvetica" class=""><br class="">Zewo is the outlier here, but I would like to note as a contributor to
Zewo that we have not ran into situations where value semantics create
an impassable roadblock. </font><font size="3" class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">To me, it makes sense to pass them around as values since they don't have
any logic of their own. Requests/Responses can't send themselves, they
can only read and modified. It also gives me as a user more safety to pass
them around since I know that they won't be modified implicitly.</font><font size="3" class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">Take the following pseudo-code as an example:</font><font size="3" class=""> <br class=""></font><font size="1" face="Helvetica" class=""><br class="">HTTPServer.onRequest { request in</font><font size="3" class=""> </font><font size="1" face="Helvetica" class=""><br class=""> print(request.sourceIp)</font><font size="3" class=""> </font><font size="1" face="Helvetica" class=""><br class=""> HTTPClient.send(request)</font><font size="3" class=""> </font><font size="1" face="Helvetica" class=""><br class=""> print(request.sourceIp)</font><font size="3" class=""> <br class=""></font><font size="1" face="Helvetica" class=""><br class="">}</font><font size="3" class=""> <br class=""></font><font size="1" face="Helvetica" class=""><br class="">With reference semantics, there is no guarantee that sourceIp will be the
same before and after sending off the request. After all, it <i class="">could</i>make sense for the HTTPClient to modify the sourceIp before sending off
the request. This of course a contrived example, but the point stands.</font><font size="3" class=""><br class=""><br class=""><br class="">Not contrived at all, this is a perfect illustration of why reference semantics
make it harder to reason about your code and identify the cause of bugs.
<br class=""></font><font size="1" face="Helvetica" class=""><br class="">Anyway, I think it would be great if we could have people talk about their
own experiences.</font><font size="3" class=""> <br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">>3. When is it more convenient to have reference semantics?</font><font size="3" class=""><br class=""><br class=""><br class=""><br class="">Convenience is a double-edged thing. Pointers with possibly-null values,
or integer indexes into Unicode strings, are often considered convenient.
But that convenience comes with a hidden cost to correctness – unexpected
nulls, accidentally indexing into the middle of a grapheme cluster etc.
When making a proper effort to handle these things correctly, code quickly
becomes less convenient, and less readable, compared to the alternatives.
<br class=""><br class="">It’s generally the style in Swift that correctness shouldn't be sacrificed
for convenience, but when things work out well, convenience and ergonomics
can be mutually reinforcing – the code is nice to use correctly, awkward
to use incorrectly. For example, optionals that force you to handle nil
help with correctness, but they have sugar like ?? or optional chaining
to handle common patterns clearly and idiomatically, ! as a shorthand for
asserting something is non-nil etc. <br class=""></font><font size="1" face="Helvetica" class=""><br class="">In the middleware chain architecture that we decided on in Zewo (the other
ones have something similar), it can be convenient to modify requests in
the responder and have that reflect in the middleware. I think this problem
is best solved with `inout` parameters rather than reference types, but
that is my personal opinion.</font><font size="3" class=""> <br class=""><br class=""><br class="">FWIW, this design view is also strongly held by those of us working on
the Swift Standard Library. I also brought this up with several members
of the Core Team and they also strongly felt that inout and value types
was the general approach we should take with such types in Swift. The consensus
there was that reference types really should be mostly used when identity
of the value is important. <br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">>4. Are there problems that can't be solved with value semantics?</font><font size="3" class=""><br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">I haven't found any, but I'm sure others can bring something interesting
to the table.</font><font size="3" class=""> <br class=""><br class=""><br class=""><br class="">Shared mutable state is one. With an unavoidably-shared resource, like
a network connection or a handle to a window on a screen, reference semantics
are often what you want. <br class=""><br class=""></font><font size="1" face="Helvetica" class=""><br class="">On Wed, Nov 23, 2016 at 1:07 PM Dan Appel <</font><a href="mailto:dan.appel00@gmail.com" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">dan.appel00@gmail.com</u></font></a><font size="1" face="Helvetica" class="">>
wrote:</font><font size="3" class=""> </font><font size="2" face="Helvetica" class=""><br class="">Hello everyone!</font><font size="3" class=""> <br class=""></font><font size="2" face="Helvetica" class=""><br class="">I was unable to make the kick-off meeting for the HTTP sub-team, but I
looked over the </font><a href="https://docs.google.com/document/d/1SWK0qBDi-9DeLJwHlcXcPU7h22JU-DWW8HTVuHbTQiw/edit" target="_blank" class=""><font size="2" color="blue" face="Helvetica" class=""><u class="">meeting
notes</u></font></a><font size="2" face="Helvetica" class=""> and found some topics
that I think could use some more on-the-record discussion.</font><font size="3" class=""><br class=""></font><font size="2" face="Helvetica" class=""><br class="">A few questions that I wanted to raise:</font><font size="3" class=""> <br class=""></font><font size="2" face="Helvetica" class=""><br class="">1. Do we want to use concrete types or protocols for Request/Response?</font><font size="3" class=""></font><font size="2" face="Helvetica" class=""><br class="">2. If we use concrete types, do we want value or reference semantics?</font><font size="3" class=""></font><font size="2" face="Helvetica" class=""><br class="">3. When is it more convenient to have reference semantics?</font><font size="3" class=""></font><font size="2" face="Helvetica" class=""><br class="">4. Are there problems that can't be solved with value semantics?</font><font size="3" class=""><br class=""></font><font size="2" face="Helvetica" class=""><br class="">I would like to avoid bike-shedding, and I think this can be done by providing
real examples rather than just talking about the pros and cons.</font><font size="3" class=""></font><font size="1" face="Helvetica" class=""><br class="">-- <br class="">Dan Appel</font><font size="3" class=""> </font><font size="1" face="Helvetica" class=""><br class="">-- <br class="">Dan Appel</font><font size="3" class=""> </font><font size="1" face="Helvetica" class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list</font><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="mailto:swift-server-dev@swift.org" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class=""><font size="1" color="blue" face="Helvetica" class=""><u class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></a><font size="3" class=""></font><tt class=""><font size="2" class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class=""><a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a></font></tt><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class=""><tt class=""><font size="2" color="blue" class=""><u class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></tt></a><font size="3" class=""><br class=""><br class=""></font><font size="2" face="sans-serif" class=""><br class=""><br class="">Unless stated otherwise above:<br class="">IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br class="">Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</font><tt class=""><font size="2" class="">_______________________________________________<br class="">swift-server-dev mailing list<br class=""><a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a><br class=""></font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class=""><tt class=""><font size="2" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt class=""><font size="2" class=""><br class=""></font></tt><br class=""><br class=""><br class=""></div></blockquote></div><br class=""></body></html>