<div dir="ltr">Ben and others,<div><br></div><div>One thing I'd like to address first is middleware. People keep bringing it up, and I see this as absolutely something that the serverside group has no responsibility in creating or defining paradigms for. The focus of this group should be lower and allow frameworks to define how their middleware should be defined and act. Let's remember that many frameworks exist because there are many ideas on how a framework should look, for now, let's focus on parsing and serializing http. There's no reason to add additional responsibilities to a group already in disagreement.<br><div><br></div><div>On protocols, if this was a private project, I'd say yes, let's use something concrete and move to protocols when there are multiple use cases. In this case it's not, it's a library, and there are already multiple use cases. It is intended to be consumed by multiple different consumers/frameworks immediately. Already we have multiple stakeholders in the group with very different ideas and use cases for the model, protocolizing this would allow us to focus on parsing and let frameworks choose how to model. By opting for generics constrained to our protocol internally, the compiler will inline the code and give us pretty good performance, in our generic constrained code, it was just as fast, or faster than it's model counterparts.</div><div><br></div></div><div>Here's an example of a protocol required to parse a request<br><br>```</div><div>protocol HTTPMessage {<br> init(status: String, version: String, method: String, headers: [String: String], etc...<br>}<br>```<br><br></div><div>It doesn't need to be anything particularly complex, and we could include easily the inverse as well for the serializer. This could be a distinct protocol even for use cases we might not consider.</div><div><br></div><div>I'd like to just put up a quick reminder that we're not building a framework here, we're building core apis that are intended to be flexible and useful for framework developers. With something like this, we could easily conform foundation's URLRequest or NSURLRequest by default so basic users could use those built in without much effort, but framework developers wouldn't be stuck constantly dealing with non-native objects or doing unnecessary conversions.</div><div><br></div><div>This doesn't take away from anything that has been proposed so far, and creates additional capabilities and flexibilities for a system that is intended to be just that ... flexible. In general, I think it's important for us to remind ourselves what we're building and that creating the most flexible possible code will make the library more lasting and allow users to create unique and interesting interactions that we might not have even considered in our narrow scope. We want to support and encourage this creativity, not stifle it, wherever possible. Looking forward to working through more of this.</div><div><br></div><div>- Logan</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 22, 2017 at 6:41 PM Swizzlr via swift-server-dev <<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"></span></div><div class="gmail_msg"><div class="gmail_msg">I think protocols by their self evident definition of an interface only will allow the HTTP library implementors to provide a consistent and stable interface that we can internally reimplement (for instance, upgrade). In the face of ABI stability and resilience, protocols are going to live longest, I would think.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On the subject of middlewares, let's remember that one framework's middleware is another's shared data nightmare. I would fully expect many frameworks to wrap the raw HTTP requests or response streams in opinionated APIs of their own design.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Tom</div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">Sent from my iPhone</div></div></div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On 22 Mar 2017, at 13:55, Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">> <span style="font-size:12.8px" class="gmail_msg">Protocols in Swift exist primarily to allow code to operate on multiple different concrete implementations simultaneously – either with generics as constraints, or as existentials. In this case, there is no clear reason why someone would want to write code that handles two separate implementations of an HTTP API at the same time within a single program.</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div>I completely agree with this. Using protocols to allow multiple implementations in this scenario would not be a solution for a technical problem. It would be, instead, a solution for a "human" problem which is basically the difficulty of reaching an agreement. In the end what we all want is the best solution technically.</div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On 22 March 2017 at 10:19, Ben Cohen via swift-server-dev <span dir="ltr" class="gmail_msg"><<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 20, 2017, at 11:11 PM, Logan Wright via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:</div><br class="m_5191689983330813642m_-7671921359477866230Apple-interchange-newline gmail_msg"><div class="gmail_msg"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="gmail_msg">I'd personally like to see us more explicitly explore protocols, I haven't seen anything so far that actually requires a concrete model and would perhaps be an easier way for us to reach consensus.</span></div></blockquote></div><br class="gmail_msg"></span><div class="gmail_msg">Hi Logan,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What is it about protocols that you feel would help here? In general, the relationship between concrete implementations and protocols should be that the former comes first, then the latter. Start with a concrete type, then as you move to multiple diverse implementations, factor out the common things that unify those types.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Protocols in Swift exist primarily to allow code to operate on multiple different concrete implementations simultaneously – either with generics as constraints, or as existentials. In this case, there is no clear reason why someone would want to write code that handles two separate implementations of an HTTP API at the same time within a single program. Protocols are not necessary in order to “swap” implementation A for implementation B. All that is needed for this is that the two implementations be source compatible i.e. have the same method signatures (protocols are a way of helping enforce that, but there are other less performance-consequential ways of doing it too).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Now, it may be that a need does emerge as the design takes shape to have separate types, say, for different kinds of HTTP connections, that might need to be handled by the same program and have to be unified via a protocol to enable handling code to be shared across both. But this protocol should be discovered through the process of looking at the common features the different concrete types have, rather than designed up front.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Cheers,</div><div class="gmail_msg">Ben</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg">_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div><br class="gmail_msg"></div>
</div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-server-dev mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></span><br class="gmail_msg"></div></blockquote></div></div>_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
</blockquote></div>