[swift-server-dev] Next HTTP API meeting

[Yan Ka Chiu]

I agree. Let's not be too picky on Logan's example. It's just an example. :)

I personally think that http header/components are better define as Collection<HTTPHeader>. In fact it can even be Collection<HTTPComponent> where HTTPComponent is an enum of .statusline, .header, .data but whatever, detail implementation is not important at this point.

 In general, I think protocol is the best for the job. In fact if we use protocol we probably don't even worry about value/reference semantic problem here.  

Just leave it and let the user decide what they want to use. We really only need an abstract interface to implement a HTTP parser, this is what protocol for in the first place. 

Someone might prefer an array to store headers, someone might prefer a linked list (or other custom data structures). We really don't have to care. 

Michael

Sent from my iPhone

> On Mar 23, 2017, at 3:00 AM, Alex Blewitt via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> 
>> On 23 Mar 2017, at 09:51, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>> 
>> Here's an example of a protocol required to parse a request
> 
> I agree in principle, thinking in protocols is a good way of defining what an API should look like and how it should interact.
> 
>> ```
>> protocol HTTPMessage {
>>    init(status: String, version: String, method: String, headers: [String: String], etc...
>> }
>> ```
> 
> This is a good example, in that it brings up a number of other questions. For example: the 'status' is a String here. Why not an enum or an int?
> 
> In addition, the headers are a dictionary of [String:String]. However, HTTP headers can be repeated and it's possible to get the first or a list of values for the repeated header, so using a dictionary isn't sufficient. In addition the headers dictionary has an implicit assumption about the fact they're stored as values (for example). You'd need to have a separate protocol for representing the headers in order to permit multiple implementations.
> 
> Discussing the protocols helps understand the problems from two perspectives; from an end user's view of the software, and from a framework implementor's view of the software.
> 
>> 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.
>> 
>> 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.
>> 
>> 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.
> 
> 
> Alex
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev