[swift-server-dev] Sockets API

[Chris Bailey]

> Or are you actually talking about the native S/390 OS running Swift?

Yes I was ;-) 

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

At the moment, the hope is that people will express interest and opinions 
on what's required, and sign up to the work group. The only decisions that 
have been "pre-made" are what's documented on the Swift.org project page, 
covering the goals, focus areas, and development process. You'll notice 
that the development process starts with an "API proposal" which is 
published as a "pitch" in the Swift Evolution process.

The aim is very much that the proposals, API designs, and resultant 
libraries are driven by the whole community.

Chris




From:   Helge Heß via swift-server-dev <swift-server-dev at swift.org>
To:     Swift Server Dev <swift-server-dev at swift.org>
Date:   31/10/2016 00:19
Subject:        Re: [swift-server-dev] Sockets API
Sent by:        swift-server-dev-bounces at swift.org



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

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161031/6971a731/attachment.html>