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

Joy Keys proyb7 at gmail.com
Tue Apr 4 05:56:19 CDT 2017


How about TLSExchange which sound more like what discussion is about?

On Tuesday, April 4, 2017, Georgios Moschovitis via swift-server-dev <
swift-server-dev at swift.org> wrote:

>
> On 3 Apr 2017, at 5:33 PM, Gelareh Taban <gtaban at us.ibm.com
> <javascript:_e(%7B%7D,'cvml','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/3d6d9d4a/attachment.html>


More information about the swift-server-dev mailing list