[swift-server-dev] Draft proposal for TLS Service APIs (please review)
george.moschovitis at icloud.com
Tue Apr 4 03:18:46 CDT 2017
> 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?
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...
More information about the swift-server-dev