Enable byterange when DAP is enabled? [was: questions about the --enable-byterange configure option]

[edwardhartnett]

I just read about the byterange feature in the docs.

Can byterange be always on @DennisHeimbigner? That is, can we remove the --enable-byterange option? I could not see any reason why not.

Every enable option doubles (ideally) our test burden. We don't want that, and we also don't want a bunch of code that goes from version to version without being tested (is this code being tested in Travis?). I can add --enable-byterange to some of my CI jobs.

We have --disable-netcdf-4 because sometimes users need netcdf classic on machines with no HDF5. Is there an equivalent reason people would build with --disable-byterange?

If not, let's turn this feature on always and take out the configure option. That will simplify code and testing.

As it is now, very few users will see this feature, since it is off by default. Even if we keep the option, shouldn't it be on by default?

(Also, similar to #1390, --enable-byterange has a problem if used with --disable-dap, so a simple check in configure.ac would be a good idea if we can't get rid of --enable-byterange.)

[DennisHeimbigner]

Do you care that byterange requires libcurl to work?

[WardF]

I would think that having byterange enabled whenever DAP4 is enabled would be ok. I can't imagine a situation when DAP would be turned on, but byterange would need to be disabled (althought I'm open to being corrected). What do you think, @DennisHeimbigner ?

[DennisHeimbigner]

Well technically byterange is independent of DAP. It is similar in the
sense that it requires libcurl but it does not require any of the DAP code
either DAP2 or DAP4.

[WardF]

That seems a straightforward answer, thanks @DennisHeimbigner. Should byterange be enabled when the required features of libcurl are available? Do we even look for/link against libcurl when DAP is completely disabled? Let's discuss this at the next meeting, the configure-time logic may become a little convoluted. I'm working on a support question currently, but want to go try something.

[edhartnett]

The general rule we follow is that, once a feature is no longer experimental, we enable it automatically if the system supports it.

This is helpful for CI testing, because then the feature will start to be tested automatically on most CI builds. If we leave this feature as is, it will not be tested on any CI builds which do not explicitly do --enable-byterange.

But what happens if curl is not there? Normally we would error out, and tell the user to either install curl or build with --disable-byterange (just as we do with dap when curl is not present).