[swift-server-dev] HTTP Parser

[Paulo Faria]

Hi Tony!

I’m glad that you touched this subject. That’s something I think we should sort out early. How is the relationship between the Swift Server APIs and Foundation going to be. I think we can all agree that we don’t want duplicate APIs, and I love that you’re willing to do what it takes for it. I just worry about this specific line you said:

> or design the server API to fit in with Foundation.

The reason I don’t think this is the best solution is because Foundation wasn’t designed for Swift. It uses concepts which are very well aligned with Objective-C, and it works beautifully there. I can see the effort on making Foundation be more Swifty, but I’m not sure about the level of changes you’re willing to go to make this happen. Specially because the biggest difference is on the programming paradigm used. Foundation uses OOP favoring reference types and inheritance as the main paradigm. We all know that Swift on the other hand proposes a whole new paradigm POP (Protocol oriented programming) favoring value types and protocols. Is it realistic to expect that Foundation on Swift would be changed to use this paradigm while maintaining Objective-C’s foundation with it’s original paradigm? I feel the weight of legacy will have a big impact on the design if we decide to make the server APIs work with Foundation instead of the other way around. I see the Swift Server APIs as a chance to design libraries that are 100% design with the beauty of Swift in mind. If we adapt to Foundation I feel a lot of that will be lost. I’m not saying we should just ditch Foundation. What I would love to see is a true Swift Foundation and the Server APIs sharing code with it.


> On Nov 4, 2016, at 7:38 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 4 Nov 2016, at 21:34, Brent Royal-Gordon <brent at architechies.com> wrote:
>> Here's my question: Can we have our HTTP parser use Foundation's existing `URLRequest` and `HTTPURLResponse` types as Swift-facing outputs and inputs?
> 
> I did that in a Swift 2 GCD (and http-parser) based iOS HTTP proxy for a customer project. That is, parse stuff into NSURLRequest and NSHTTPURLResponse. I think in general this is the right approach to do this, but I also ran into a few issues. E.g. one was that NSURLRequest takes an NSURL, hence it can’t be used as-is for a `CONNECT host:port …` request.
> 
> The other thing I dislike about the two is that the API isn’t symmetric. E.g. in NSURLRequest you grab the headers via 
> 
>  var allHTTPHeaderFields: [String : String]?
> 
> whereas in NSHTTPURLResponse you do:
> 
>  var allHeaderFields: [AnyHashable : Any]
> 
> NSURLRequest has
> 
>  func value(forHTTPHeaderField: String)
> 
> which NSHTTPURLResponse doesn’t have, etc.
> 
> But I suppose stuff like that should be fixed in Foundation too. And it isn’t a blocker, I ended up writing extensions for such.
> And maybe that is the right solution for Swift-Server: Have protocols for that and let the two be just one implementation of them. E.g. a libcurl C request struct could be another. 
> 
> 
> Having said that: there is one detail which may be hard for the API as it may tie into the way the I/O is done: the body streams. In my project I just used the two classes for the headers only.
> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev