[swift-server-dev] Convert HTTPVersion to struct

[Tanner Nelson]

Requiring a new version to support new features and having existing code be
compatible with a new version are two different things.

On Wed, Jun 14, 2017 at 12:44 Rien <Rien at balancingrock.nl> wrote:

>
> > On 14 Jun 2017, at 13:29, Tanner Nelson <tanner at vapor.codes> wrote:
> >
> > Unless there is a need to be able to exhaustively switch over all
> supported HTTP versions, using an enum seems overly restrictive. Especially
> when considering that adding or removing cases from enums is a breaking
> change (requires a major version bump).
>
> I presume that supporting a new HTTP version will always require a major
> version bump.
>
> Rien.
>
>
> > As authors of a general purpose HTTP package, we should be avoiding
> unnecessary restrictions wherever possible.
> >
> > As an aside, Go also uses two integers to represent major and minor.
> https://golang.org/pkg/net/http/#Request
> > On Wed, Jun 14, 2017 at 11:38 Rien via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > > On 14 Jun 2017, at 12:11, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> > >
> > > On 14. Jun 2017, at 11:36, Rien via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> > >>> On 14 Jun 2017, at 11:14, Chris Bailey <BAILEYC at uk.ibm.com> wrote:
> > >>>
> > >>> One factor is whether you consider the version to be discrete values
> or a structured format for data - I'd argue that we have a structured
> format due to the expectation that future versions of the HTTP spec could
> arrive.
> > >>
> > >> But do you want your code littered with numerical tests or conceptual
> tests?
> > >> Suppose a new version of HTTP does arrive, do you really want to
> manually walk through the code and find all tests on the numerical values?
> > >> Or would it be easier to use switch statements on an enum and have
> all missing cases pointed out to you?
> > >
> > > This is actually a argument *for* using numbers. When using an enum in
> an API makes the same break every time you change it. And that is killer
> for a an API representing a living protocol like HTTP.
> > >
> > > Also in proper source you would check for: `if major >= 2`, not `==`,
> another advantage of using version _numbers_.
> > >
> > > In the context of HTTPVersion
> >
> > Precisely. I am making the argument for enum’s only for the HTTPVersion
> since it is such a unique feature.
> >
> >
> > > I think there shouldn’t be too much discussion though, for two reasons:
> > > - If we get HTTP/3.x, we almost certainly have a new API revision.
> >
> > Absolutely.
> >
> > > - The HTTP version should only matter for logging purposes. The
> differences in capabilities
> > >  should be handled by the implementation (e.g. keep alive vs not,
> multiplexing or not, etc).
> >
> > Agreed, which is why the decision should be made carefully. An API
> developer usually sees things differently from an API user. Conceptually a
> version number is just a tag. It does not represent a numerical value.
> Which makes testing for numerical values error prone, which leads to your
> following point:
> >
> > >  In other words, you should never have to check for the versions, but
> rather features.
> >
> > Again, fully agreed. But which I interpret as an argument in favour of
> enums...
> >
> > Rien.
> >
> > >
> > > hh
> > >
> > > _______________________________________________
> > > swift-server-dev mailing list
> > > swift-server-dev at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170614/21402f14/attachment.html>