PR 96 - async server

Helge_Hess1 · November 19, 2017, 4:23pm

Hi,

so what is the general feeling wrt

GCD based, Asynchronous Implementation of the API by helje5 · Pull Request #96 · swift-server/http · GitHub

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_Hess1 · November 19, 2017, 8:02pm

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_Nelson2 · November 20, 2017, 12:04am

"Base Networking" under "Focus Areas".

This was the first and last meeting:

github.com

swift-server/work-group/blob/master/meetings/networking/2016-11-04/minutes.md

# Networking sub-team kick-off

### Initial Agenda:
* Introductions
* Goals
* Development process overview
* Next Steps

### Attendees:
* Chris Bailey - IBM, Kitura and Swift.org stuff
* William Dillon (hpux735) - Swift-ARM, embedded systems, mac, linux, etc
* Alfredo Delli Bovi - contributions to Swift core. Background in Node.js/PHP
* Steve Algernon - Apple, CF, CFNetwork, NSURLSession
* Paulo Faria - Zewo
* Thiago Holanda - Zewo, iOS Developer and Python.
* Morgan Lieberthal - Mac / backend web developer
* John Lin - iOS dev, Ruby, Python & Erlang
* Illia Tykhonkov - iOS developer
* Matt DeFoor - Condrey Corporation
* Piers Mainwaring - Backend web dev

This file has been truncated. show original

···

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
>>
>> GCD based, Asynchronous Implementation of the API by helje5 · Pull Request #96 · swift-server/http · GitHub
>>
>> 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_Hess1 · November 20, 2017, 12:55am

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 ;-)

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
>>
>> GCD based, Asynchronous Implementation of the API by helje5 · Pull Request #96 · swift-server/http · GitHub
>>
>> 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