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

[Helge Heß]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170323/b49394e2/attachment.sig>