<font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</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">Michael Chiu 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">Helge Heß <me@helgehess.eu></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">swift-server-dev@swift.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">29/10/2016 01:45</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=3>> You need to elaborate a little more. “is not
standardised across platforms at all”. In my eyes the reverse is true,
the socket API *is* standardised by Posix and even Winsock2 is virtually
identical to the Unix one (being just a Windows port of the BSD one).<br>
> Yes there are a lot of small differences and various extensions, but
nothing fundamental unless you want to get really advanced.</font></tt>
<br><tt><font size=3>The sockaddr part is definitely not standardized,
and that is what I really mean since sockaddr is almost unavoidable when
using socket. If sockaddr is not standardized, socket is not standardized.
I apologize for not making myself clear. </font></tt>
<br><tt><font size=3>> Differences in size and alignment are completely
handled by the clang C mapping and of no concern at all to the user of
those structs?</font></tt>
<br><tt><font size=3>Not when in when BSD has 104 bytes in sockaddr_un.sun_path
and Linux has 104. Plus BSD has extra sa_len component.</font></tt>
<br><tt><font size=3>> Absolutely, the raw structs are hard to use as-is.
But since you can extend C structs in Swift you can make them really nice.<br>
</font></tt>
<br><tt><font size=3>I agree with you, that’s why we should include in
the api. </font></tt>
<br><tt><font size=3>This is my implementation (sockaddr family as enums)
btw: </font></tt><a href=https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift><tt><font size=3 color=blue><u>https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift</u></font></tt></a><tt><font size=3>.</font></tt>
<br><tt><font size=3>> Yes, agreed. There should be protocols for such
stuff. What is your opinion on my point:<br>
<br>
> ><i> 3) Do you really want just a Socket, or is what you really
want<br>
</i>> ><i> a (byte) stream framework?</i></font></tt>
<br><tt><font size=3>I’ll say I think just socket, my overall approach
is, make an independent layer for socket.</font></tt>
<br><tt><font size=3>Then after all if we decide to build default stream
framework/event looping as well, we can simply build it separately and
make socket compatible with it. </font></tt>
<br><tt><font size=3>If we going to need socket anyway, why don’t we open
up more opportunities for developers as well?</font></tt>
<br><tt><font size=3> </font></tt>
<br><tt><font size=3>Off topic: Can you cc me a copy as well when you reply?
Since somehow I can only see your response and reply manually from Archive,
and I’d like to discuss with you more.</font></tt>
<br>
<br><tt><font size=3>Sincerely,</font></tt>
<br><tt><font size=3>Michael</font></tt>
<br>
<br><tt><font size=2>_______________________________________________<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>