<html><body><p><tt><font size="2">There are 2 hard problems in computer science: cache invalidation, </font></tt><tt><font size="2">**naming things</font></tt><tt><font size="2">**, and off-by-1 errors. -- Leon Bambrick</font></tt><br><br><tt><font size="2">:-) </font></tt><br><br><br><tt><font size="2">> > * These are essentially delegate methods notifying the TLS engine of an event. </font></tt><br><tt><font size="2">> > `onAccept` says that the system has accepted a connection and the TLS engine should </font></tt><br><tt><font size="2">> > do what it needs to do with it, `onSend` means the system is about to send data and </font></tt><br><tt><font size="2">> > it needs the TLS engine to modify it, etc. If so, Swift APIs more often use words like </font></tt><br><tt><font size="2">> > `should`, `will`, or `did` than `on`, particularly since they're more precise about the </font></tt><br><tt><font size="2">> > timing of the delegate method compared to the actual event.<br>> <br>> +1 onXXX methods look definitely non-Swifty to me.</font></tt><br><br><br><tt><font size="2">Fair enough. What do you recommend?</font></tt><br><br><tt><font size="2"><br>> <br>> One other thing that bothers me is the `Service` postfix of the main protocol.<br>> `Service` is a common name used in higher-level applications.<br>> <br>> Maybe we could replace it with another postfix (e.g. `Engine`) or even drop it completely?</font></tt><br><br><br><tt><font size="2">I agree that Service is not a particularly good name but that was the best I could think of. I liked Engine but (1) we are not implementing anything, just overlaying and (2) I didnt want any confusion with with the SSL Engine of OpenSSL.</font></tt><br><br><tt><font size="2">So again, I would be interested in your recommendations!</font></tt><br><tt><font size="2"><br><br>gelareh</font></tt><br><br><br><br><br><img width="16" height="16" src="cid:1__=8FBB0A64DFDCA9B68f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Georgios Moschovitis ---04/01/2017 01:23:58 AM---> * These are essentially delegate methods notifying"><font size="2" color="#424282">Georgios Moschovitis ---04/01/2017 01:23:58 AM---> * These are essentially delegate methods notifying the TLS engine of an event. `onAccept` says tha</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Georgios Moschovitis <george.moschovitis@icloud.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Brent Royal-Gordon <brent@architechies.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Gelareh Taban/Austin/IBM@IBMUS, swift-server-dev@swift.org, Bill Abt/Cambridge/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">04/01/2017 01:23 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [swift-server-dev] Draft proposal for TLS Service APIs (please review)</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">> * These are essentially delegate methods notifying the TLS engine of an event. `onAccept` says that the system has accepted a connection and the TLS engine should do what it needs to do with it, `onSend` means the system is about to send data and it needs the TLS engine to modify it, etc. If so, Swift APIs more often use words like `should`, `will`, or `did` than `on`, particularly since they're more precise about the timing of the delegate method compared to the actual event.<br><br>+1 onXXX methods look definitely non-Swifty to me.<br><br>One other thing that bothers me is the `Service` postfix of the main protocol.<br>`Service` is a common name used in higher-level applications.<br><br>Maybe we could replace it with another postfix (e.g. `Engine`) or even drop it completely?<br><br>-g.<br></font></tt><br><br><BR>
</body></html>