[swift-server-dev] Sockets API

[Daniel A. Steffen]

> On Oct 30, 2016, at 17:18, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 30 Oct 2016, at 19:50, Chris Bailey <BAILEYC at uk.ibm.com> wrote:
>> One of the primary goals is around platform support, and whilst most platforms generally provide some level of POSIX or POSIX-like APIs, we can't guarantee that for all platforms that Swift is ever likely to support. We know that Windows is a platform that we'll likely need to support in the near future, and that is generally different enough that having a thin layer over POSIX starts to be come problematic - particularly around error handling. If we then need/want to start providing in async socket handling constructs, then we have the further challenge of dealing with epoll vs machports vs Windows event waiting. 
> 
> To be honest my assumption was that libdispatch is supposedly fully supported on all Swift platforms. And libdispatch provides an abstraction for the async event handling.
> 
> Can you confirm that you consider libdispatch inadequate as a server side async IO framework?

I think we need to be careful to distinguish two separate pieces of functionality in this area provided by libdispatch:

	1) dispatch sources: this is the generic eventing primitive in libdispatch, for various types of event sources including file descriptors
	2) dispatch_io: this is a asynchronous IO facility built on top of dispatch sources (and advisory reads for disk IO)

I can easily believe that 2) might be too high level/abstracted and missing functionality for a server networking framework esp. around encryption (that is not what it was designed for), but I would strongly encourage you to stay with 1) for the raw event listening/handling.

The event/source layer in corelibs-libdispatch is where we already have the abstraction layer for kevent vs epoll vs … and if additional support for another platform is required that is where it should be added.

we are continuing to put significant resources into making this layer better and more tightly integrated with the Darwin kernel in particular, as well as providing additional primitives esp for server workloads (more on that soon) and are also committed to make these APIs continue to work well as the Swift concurrency story evolves.

Daniel

> 
> 
>> Beyond Windows, I know that there's interest in adding Swift support for additional platforms that have further differences - support for s390 mainframes in particular would add additional complexities.   
> 
> I’ve ported a reasonably large ObjC app server/application from Linux ix86 to Linux S/390 many years ago and don’t remember any particular differences. Could you elaborate where you see the issue here?
> Or are you actually talking about the native S/390 OS running Swift?
> 
> 
>> There's also the Swift API Design Guidelines to consider, with the strive towards the use of fluent usage and plain language terms. Whilst the POSIX APIs may make sense to existing systems programmers, or people who understand the implementations of the underlying protocols etc, I would argue that they're somewhat daunting to programming learning systems programming for the first time. 
> 
> Absolutely. Two things:
> 
> a) I thought the idea of this group was to provide a foundation for
>   authors of higher level frameworks, not end-users (developers).
>   No one would assume that a Berlin or SF hipster has to deal with
>   Posix, hell no! :-)
>   Clearly all the existent frameworks did manage to deal with the
>   Posix APIs. Or else they wouldn’t exist.
> 
> b) I still think that the Posix APIs can be made quite Swifty via 
>   protocols and extensions w/o the need to actually wrap them.
>   (and provided examples demonstrating that ...)
> 
> 
>> That's not to say a thin layer over the POSIX socket APIs, that looks a lot like the POSIX APIs won't drop out as the answer - more that we should focus on the use cases and what the APIs should look like, and then look to see how we can implement that most easily. 
> 
> Sounds good too. To be honest I’m actually a little unsure how this group is supposed to work. Is someone submitting a proposal for an API via a pull request and then this is discussed? Or do we discuss on this mailing list on what the actual goal is? Or has Apple/IBM setup a group to implement an API and will ‘just do it’? ("we actually have some of the contributors/committers for Netty signed up to the work group” sounds a litte like this :-)
> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev