[swift-server-dev] Draft proposal for TLS Service APIs (pleasereview)

[Bill Abt]

I agree with Gelareh with regard to this.  The TLSService should be the lowest layer and closest to the C API.  Async I/O can be added at a higher level later on and still use TLSService.  Additional read/write methods supporting different input/output types again, could be added at a higher level..  As the TLSService is currently designed, any number of separate higher level implementations can be built on top of it.  I think this gives the most flexibility both now and in the future.

-Bill Abt


> On Mar 23, 2017, at 12:53 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> Hi Gelareh,
> 
> I suppose what you have been saying about EAGAIN etc may work out. It would be really nice to actually try the API with an NIO consumer, did you do this already? Just to make sure and test out that we aren’t missing something.
> 
> 
> Wrt the GCD channel stuff. Well, your design has that separate service object which is ‘used' by some ‘Socket’ class. With GCD in mind I would design the TLS support as a new custom channel which is just wrapping a GCD channel. It would provide the same API like GCD plus the necessary extras. Kinda like OpenSSL BIOs, just with async.
> 
> But this would tie the I/O to a GCD API style (not necessarily to GCD, you could factor out the channel API as a ’stream' protocol). Quite likely this is still not desirable for everyone.
> 
> 
> I haven’t seen a proposal on how (byte) streams are going to work for Server Side Swift (i.e. how the API of the HTTP Request/Response body streams would look like). That kinda ties into this.
> 
> 
> Summary: The service object as you proposed should be fine as a support wrapper used by higher level I/O objects. I guess it is the right way to go to support various I/O styles. Just wrap OpenSSL and the macOS thing. Do not add anything else.
> But *if* we would get a proper (byte) streaming abstraction, I would prefer if a TLS stream would live on top of this (be a stream itself and wrap the stream representing the connection).
> 
> hh
> 
>> On 23 Mar 2017, at 16:52, Gelareh Taban <gtaban at us.ibm.com> wrote:
>> 
>> Btw Helge, really interesting about the GCD channel APIs. How would your propose they be integrated? Would they replace or modify onSend/onReceive methods?
> 
> _______________________________________________
> 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/20170323/7a6bcce8/attachment.html>