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

[Georgios Moschovitis]

> On 3 Apr 2017, at 5:33 PM, Gelareh Taban <gtaban at us.ibm.com> wrote:
> 
> There are 2 hard problems in computer science: cache invalidation, **naming things**, and off-by-1 errors. -- Leon Bambrick
> 
> :-) 
> 
> 
> > > * 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.
> > 
> > +1 onXXX methods look definitely non-Swifty to me.
> 
> 
> Fair enough. What do you recommend?
> 
what about:

onAccept -> didAccept
onDestroy -> didDestroy / wasDestroyed
onClientCreate -> clientWasCreated
onServerCreate -> serverWasCreated
…

etc, you get the point.
> 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.
> 
> So again, I would be interested in your recommendations!
> 
(1) `Service` has the same problem
      if it’s just overlaying, maybe you should name it ‘TLSOverlay’, ‘TLSMiddleware’ or something.
      I still think, `Engine` is a pretty good name though, but will keep thinking for better ones.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170404/8ee88dff/attachment.html>