[swift-server-dev] Sockets API
BAILEYC at uk.ibm.com
Sun Oct 30 13:50:15 CDT 2016
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.
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.
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.
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.
From: Michael Chiu via swift-server-dev <swift-server-dev at swift.org>
To: Helge Heß <me at helgehess.eu>
Cc: swift-server-dev at swift.org
Date: 29/10/2016 01:45
Subject: Re: [swift-server-dev] Sockets API
Sent by: swift-server-dev-bounces at swift.org
> 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).
> Yes there are a lot of small differences and various extensions, but
nothing fundamental unless you want to get really advanced.
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.
> 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?
Not when in when BSD has 104 bytes in sockaddr_un.sun_path and Linux has
104. Plus BSD has extra sa_len component.
> 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.
I agree with you, that’s why we should include in the api.
This is my implementation (sockaddr family as enums) btw:
> Yes, agreed. There should be protocols for such stuff. What is your
opinion on my point:
> > 3) Do you really want just a Socket, or is what you really want
> > a (byte) stream framework?
I’ll say I think just socket, my overall approach is, make an independent
layer for socket.
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.
If we going to need socket anyway, why don’t we open up more opportunities
for developers as well?
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.
swift-server-dev mailing list
swift-server-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-server-dev