[swift-server-dev] Sockets API

[Chris Bailey]

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.

Chris




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: 
https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift
.
> 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.

Sincerely,
Michael

_______________________________________________
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/20161030/1e25e6ca/attachment.html>