[swift-server-dev] HTTP Parser

[Paulo Faria]

> But as part of this project you need to form a group opinion and telling someone else his idea about this is wasted time may not be the best approach 

I didn’t say the idea is a waste of time. I said implementing and maintaining everything in Swift would be very time-consuming. And that’s not an attack on this idea at all. I’m really sorry and I apologize if it sounded that way. I was just pragmatically pointing that it would take longer for us to achieve our goal that way. 


> On Nov 4, 2016, at 7:07 PM, Tony Parker <anthony.parker at apple.com> wrote:
> 
> Hi Paulo,
> 
>> On Nov 4, 2016, at 1:58 PM, Paulo Faria via swift-server-dev <swift-server-dev at swift.org> wrote:
>> 
>> The design of Foundation’s HTTP request/response is very tied to Foundation. I’d prefer we come up with our own design. Even though the name of the work group is Swift Server APIs, we’re still developing solutions for clients that could be used on the server side. An HTTP client for example. Because we have different frameworks with different concurrency models we need a design that’s flexible enough for that. Trying to adapt `URLRequest` and `HTTPURLResponse` would first, impact existing applications that use it on iOS for example, and second, we might not have enough freedom with the API design to accomplish that. Even if the Foundation team is in favor of changing the design, there’s only a small level of change in the design we can make so the API doesn’t feel alien to the rest of Foundation.
>> 
>> If you’re thinking about iOS specifically. I think some of the libraries we build here could certainly be used there as well. I can see an HTTP client built from this effort running on iOS. This way we don’t mess around with existing software. We all know people don’t like when their code breaks.
>> 
> 
> I think if the API design feels “alien” to Foundation, then we either need to update the Foundation API to feel like it fits in with Swift or design the server API to fit in with Foundation.
> 
> I’ll keep pushing for this throughout the process. It’s really important that we have a coherent stack of software from top to bottom. Ending up with different model objects for URLRequest used in the same app via two frameworks would be really unfortunate.
> 
> This comes at a cost, of course, but consistency is not something we should dismiss so easily right out of the gate.
> 
> - Tony
> 
>> 
>>> On Nov 4, 2016, at 6:34 PM, Brent Royal-Gordon via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> 
>>>> On Nov 4, 2016, at 12:18 PM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>>>> 
>>>> Helge, if I had my way, we wouldn't touch C in any way whatsoever for any of the server side libraries except as an absolute last resort, but this life is full of compromise, and I'm trying to be amicable to come up with solutions that we can agree on.
>>>> 
>>>> For HTTP2 as well, I'd like plans to eventually move to pure swift native implementations rethought for the language. 
>>> 
>>> I think the right solution in general is to use C quite aggressively at first, but wall it off behind Swift facades. Later, we can revisit our C dependencies and replace them with Swift as we feel it's appropriate. Ideally, we'd use protocols here so the replacement is as simple as possible.
>>> 
>>> Here's my question: Can we have our HTTP parser use Foundation's existing `URLRequest` and `HTTPURLResponse` types as Swift-facing outputs and inputs?  Or are these types too-tightly designed for an HTTP client's needs, and we need different types for an HTTP server? Or are there minor modifications the Foundation team is willing to make in Apple Foundation to extend them for our use case? If we *can* use these types on both client and server, I think that would be ideal—it would allow people to reuse their knowledge and potentially a little bit of code.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> _______________________________________________
>>> 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
>