[swift-server-dev] Posix Module

[Johannes Weiß]

Hi Helge,

FWIW, I posted to swift-evolution:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161031/028627.html

Cheers,
  johannes

> On 1 Nov 2016, at 10:41, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> Hi Johannes,
> 
> On 31 Oct 2016, at 10:36, Johannes Weiß <johannesweiss at apple.com> wrote:
>>> All I :-) ask for is that those Posix or C99 funds are exposed under a common name whether on Linux, Darwin, Windoze or BeOS.
>> Understood but that topic is already covered on swift-evolution.
> 
> OK, great.
> 
>> I'm more interested in making those functions usable correctly in Swift. Right now, "hard-to-use function" is an understatement IMHO
> 
> IMHO you are exaggerating quite a bit, but OK :-)
> 
>>> It probably is, so are sockets, encryption and database access :-) I think you need to start somewhere, and Swift Server is the one place which has to deal with this specific issue right now.
>> 
>> Not sure if I fully agree. I see two areas here:
>> 
>> 1) making the basic OS functionality available to Swift. IMHO that covers being able to call the OS's syscalls and being able to deal with the errors in a robust way. That for me belongs to swift-evolution but this work group could for example come up with proposals.
> 
> OK.
> 
>> 2) building libraries on top of these basic primitives. There's a bit more opinion involved here on how to do things. For example obvious questions about the programming model depending if based on Dispatch (DisptchIO or DispatchSource), one of the CSP libraries (eg. lib{dill, mill, venice}), blocking IO ;), or something else. But we should try to not bake too much opinion in these basic building blocks because that might make them incompatible with layers further up (like Zewo, Vapor, Kitura).
> 
> I think I completely agree with this. As mentioned I also think that this means it would be so low level, it essentially is little more than 'making the basic OS functionality available to Swift’. Similar to what has been done to CoreGraphics or GCD APIs.
> 
> Presumably something everyone is fighting with is TLS, primarily due to the ‘nice’ API of the relevant library :-) Having a nice Swift TLS API which doesn’t tie into specific transports would be really great (actually having one for C would be great too :-).
> 
>> Also we have to consider here that right now DispatchIO/DispatchSource is probably a reasonable place to start as Dispatch comes with Swift and a Swift API. But when (in maybe 1.5+ years) Swift gains a memory and concurrency model, Dispatch might not be the best way of doing things anymore.
> 
> I was wondering about this as well. It may not make sense to invest too much into modelling something bigger when such language changes are on the horizon?
> Don’t know, interested to see what people come up with :-)
> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev