<div>How about TLSExchange which sound more like what discussion is about?</div><br>On Tuesday, April 4, 2017, Georgios Moschovitis via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 3 Apr 2017, at 5:33 PM, Gelareh Taban &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;gtaban@us.ibm.com&#39;);" target="_blank">gtaban@us.ibm.com</a>&gt; wrote:</div><br><div><div><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">&gt; &gt; * These are essentially delegate methods notifying the TLS engine of an event. </font></tt><br><tt><font size="2">&gt; &gt; `onAccept` says that the system has accepted a connection and the TLS engine should </font></tt><br><tt><font size="2">&gt; &gt; 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">&gt; &gt; 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">&gt; &gt; `should`, `will`, or `did` than `on`, particularly since they&#39;re more precise about the </font></tt><br><tt><font size="2">&gt; &gt; timing of the delegate method compared to the actual event.<br>&gt; <br>&gt; +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></p></div></div></blockquote>what about:</div><div><br></div><div>onAccept -&gt; didAccept</div><div>onDestroy -&gt; didDestroy / wasDestroyed</div><div>onClientCreate -&gt; clientWasCreated</div><div>onServerCreate -&gt; serverWasCreated</div><div>…</div><div><br></div><div>etc, you get the point.</div><div><blockquote type="cite"><div><div><p><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></p></div></div></blockquote><div>(1) `Service` has the same problem</div><div>      if it’s just overlaying, maybe you should name it ‘TLSOverlay’, ‘TLSMiddleware’ or something.</div><div>      I still think, `Engine` is a pretty good name though, but will keep thinking for better ones.</div></div><br></div></blockquote>