<tt><font size=2>> Or are you actually talking about the native S/390
OS running Swift?</font></tt>
<br>
<br><font size=2 face="sans-serif">Yes I was ;-) </font>
<br>
<br><tt><font size=2>> 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 :-)</font></tt>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">The aim is very much that the proposals,
API designs, and resultant libraries are driven by the whole community.</font>
<br>
<br><font size=2 face="sans-serif">Chris<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Helge Heß via swift-server-dev
<swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Swift Server Dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">31/10/2016 00:19</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
Sockets API</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">swift-server-dev-bounces@swift.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 30 Oct 2016, at 19:50, Chris Bailey <BAILEYC@uk.ibm.com>
wrote:<br>
> 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. <br>
<br>
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.<br>
<br>
Can you confirm that you consider libdispatch inadequate as a server side
async IO framework?<br>
<br>
<br>
> 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. <br>
<br>
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?<br>
Or are you actually talking about the native S/390 OS running Swift?<br>
<br>
<br>
> 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. <br>
<br>
Absolutely. Two things:<br>
<br>
a) I thought the idea of this group was to provide a foundation for<br>
authors of higher level frameworks, not end-users (developers).<br>
No one would assume that a Berlin or SF hipster has to deal with<br>
Posix, hell no! :-)<br>
Clearly all the existent frameworks did manage to deal with the<br>
Posix APIs. Or else they wouldn’t exist.<br>
<br>
b) I still think that the Posix APIs can be made quite Swifty via <br>
protocols and extensions w/o the need to actually wrap them.<br>
(and provided examples demonstrating that ...)<br>
<br>
<br>
> 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. <br>
<br>
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 :-)<br>
<br>
hh<br>
<br>
_______________________________________________<br>
swift-server-dev mailing list<br>
swift-server-dev@swift.org<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>