PR 96 - async server


(Helge Heß) #1

Hi,

so what is the general feeling wrt

  https://github.com/swift-server/http/pull/96

do you want/plan to take this?

I’m just asking to know whether I should waste more time on it. I think the bigger change I should probably do is to not use a dispatch channel but a dispatch source (this implementation has to do buffering anyways for pipelining, so channels do not gain us much). This would avoid some copying in specific best cases and might run a little better in performance tests.

hh


(Helge Heß) #2

Hi,

makes sense to me. What is that 'Transport group’? Is that a public thing?

Sounds like it makes no sense to put more work into it right now. My PR should be fine to evaluate async behaviour of stuff the way it is.

hh

···

On 19. Nov 2017, at 19:14, Tanner Nelson <tanner@qutheory.io> wrote:

This depends on what is happening with the Transport group AFAIK. If they are still planning to release some Swift I/O implementation we should probably wait for that to implement a real HTTP server.

However, I have no idea what the time frame is there. So it could make sense to get an improved server in the HTTP lib for the time being.

Tanner

Sent from my iPhone

On Nov 19, 2017, at 11:23 AM, Helge Heß via swift-server-dev <swift-server-dev@swift.org> wrote:

Hi,

so what is the general feeling wrt

https://github.com/swift-server/http/pull/96

do you want/plan to take this?

I’m just asking to know whether I should waste more time on it. I think the bigger change I should probably do is to not use a dispatch channel but a dispatch source (this implementation has to do buffering anyways for pipelining, so channels do not gain us much). This would avoid some copying in specific best cases and might run a little better in performance tests.

hh

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev


(Tanner Nelson) #3

"Base Networking" under "Focus Areas".

This was the first and last meeting:
https://github.com/swift-server/work-group/blob/master/meetings/networking/2016-11-04/minutes.md

···

From: https://swift.org/server-apis/

On Sun, Nov 19, 2017 at 3:02 PM Helge Heß via swift-server-dev < swift-server-dev@swift.org> wrote:

Hi,

makes sense to me. What is that 'Transport group’? Is that a public thing?

Sounds like it makes no sense to put more work into it right now. My PR
should be fine to evaluate async behaviour of stuff the way it is.

hh

> On 19. Nov 2017, at 19:14, Tanner Nelson <tanner@qutheory.io> wrote:
>
> This depends on what is happening with the Transport group AFAIK. If
they are still planning to release some Swift I/O implementation we should
probably wait for that to implement a real HTTP server.
>
> However, I have no idea what the time frame is there. So it could make
sense to get an improved server in the HTTP lib for the time being.
>
> Tanner
>
> Sent from my iPhone
>
>> On Nov 19, 2017, at 11:23 AM, Helge Heß via swift-server-dev < > swift-server-dev@swift.org> wrote:
>>
>> Hi,
>>
>> so what is the general feeling wrt
>>
>> https://github.com/swift-server/http/pull/96
>>
>> do you want/plan to take this?
>>
>>
>> I’m just asking to know whether I should waste more time on it. I think
the bigger change I should probably do is to not use a dispatch channel but
a dispatch source (this implementation has to do buffering anyways for
pipelining, so channels do not gain us much). This would avoid some copying
in specific best cases and might run a little better in performance tests.
>>
>> hh
>>
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-server-dev

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev


(Helge Heß) #4

From: https://swift.org/server-apis/

"Base Networking" under "Focus Areas".

This was the first and last meeting: https://github.com/swift-server/work-group/blob/master/meetings/networking/2016-11-04/minutes.md

To be honest I’m a little confused by that. This is over a year ago. Is someone actually working on something at this front?

Are there any plans? (if this was the last meeting I assume no?)

So this is the steering team, "responsible for providing overall technical direction":

  • Chris Bailey (@seabaylea, IBM Kitura)
  • Logan Wright (@LoganWright, Vapor)
  • Paulo Faria (@paulofaria, Zewo)
  • Steve Algernon (@salgernon, Apple)

I would appreciate some steering, and responsibility :wink:

I don’t know, for I/O Foundation already has FileHandle. And GCD has channels. Is either enough? What is the goal, a real streaming library like Noze.io (maybe only supporting byte packets, not arbitrary types)? Is Swift Core doing something along the lines anyways?

Should we maybe just enhance GCD w/ protocols for the operations (so that we can have a TLS channel), and a factory to create specific types (sockets, TLS ones, etc)? That sounds like a relatively low hanging fruit.

hh

···

On Nov 20, 2017, at 1:04 AM, Tanner Nelson <tanner@vapor.codes> wrote:

On Sun, Nov 19, 2017 at 3:02 PM Helge Heß via swift-server-dev <swift-server-dev@swift.org> wrote:
Hi,

makes sense to me. What is that 'Transport group’? Is that a public thing?

Sounds like it makes no sense to put more work into it right now. My PR should be fine to evaluate async behaviour of stuff the way it is.

hh

> On 19. Nov 2017, at 19:14, Tanner Nelson <tanner@qutheory.io> wrote:
>
> This depends on what is happening with the Transport group AFAIK. If they are still planning to release some Swift I/O implementation we should probably wait for that to implement a real HTTP server.
>
> However, I have no idea what the time frame is there. So it could make sense to get an improved server in the HTTP lib for the time being.
>
> Tanner
>
> Sent from my iPhone
>
>> On Nov 19, 2017, at 11:23 AM, Helge Heß via swift-server-dev <swift-server-dev@swift.org> wrote:
>>
>> Hi,
>>
>> so what is the general feeling wrt
>>
>> https://github.com/swift-server/http/pull/96
>>
>> do you want/plan to take this?
>>
>>
>> I’m just asking to know whether I should waste more time on it. I think the bigger change I should probably do is to not use a dispatch channel but a dispatch source (this implementation has to do buffering anyways for pipelining, so channels do not gain us much). This would avoid some copying in specific best cases and might run a little better in performance tests.
>>
>> hh
>>
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-server-dev

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev