[swift-server-dev] Sockets API

[Michael Chiu]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/69c92438/attachment.html>