[swift-server-dev] HTTP Parser

[Tony Parker]

> On Nov 4, 2016, at 2:55 PM, Paulo Faria via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> 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.


Without getting too much into this topic, which can quickly turn a civil discussion into something else, Foundation has been "protocol oriented" all along. This is the reason that Foundation has class clusters. NSData, NSString, NSArray, NSDictionary, NSSet, NSAttributedString, NSCalendar, NSLocale, and lots more — those are all abstract base classes, which provide a default implementation for some methods and expect subclasses to provide the implementation of a few core methods.

Now it is clearly true that Swift allows us to expand upon this by adopting multiple protocols. However, I do not believe there is such a fundamental conceptual mismatch here that we cannot preserve one of the most useful aspects of developing with the iOS, macOS SDKs - consistent types and low impedance mismatch between API at all levels of the stack.

With respect to adopting other core Swift ideas like value types: we turned 20 classes into value types last year. This included a ton of work to adopt standard library protocols and improve type safety. It is an absolutely huge surface amount of Foundation’s total API surface area. It’s a large statement about how much we value making Foundation’s API consistent for Swift.

- Tony

> 
> 
>> 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
> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev