[swift-server-dev] Sockets API

[Helge Heß]

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?


> 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