Vendor opendap-protocol in xpublish-opendap

[jhamman]

This project depends on MeteoSwiss/opendap-protocol but opendap-protocol has not been updated in nearly 3 years. @xaviernogueira opened an issue a year ago that got no response (xpublish-community/opendap-protocol#9). This seems like a bit of a problem.

Question: can we move the development of the opendap-protocol to this repo? It is just a single Python module (+ tests) and is available under the BSD 3-Clause License. If the MeteoSwiss folks pick the project back up, we could always switch back to their version.

Thoughts?

[xaviernogueira]

@jhamman so a year ago I was playing around with replacing MeteoSwiss version of the protocol. There is a lot of room for improvement there, and having a working POC was handy.

Regarding just moving it, in an ideal world differ I think the OpenDap implementation belongs in another repo. I say this bc there is larger value to the community in maintaining that, but also having the versions decoupled there could be useful. Also while it is one file it's a pretty big one that probably should have been multiple files to begin with.

Maybe make a fork that we maintain, and if they respond you could just PR back in, or properly diverge?

[jhamman]

@xaviernogueira - thanks for chiming in! Nice to see you're still watching this project.

@jhamman so a year ago I was playing around with replacing MeteoSwiss version of the protocol. There is a lot of room for improvement there, and having a working POC was handy.

100%

Regarding just moving it, in an ideal world differ I think the OpenDap implementation belongs in another repo. I say this bc there is larger value to the community in maintaining that,

I thought the same thing until I saw this: https://github.com/MeteoSwiss/opendap-protocol/network/dependents. Xpublish (and a few related projects like xreds) are the only dependencies. The project is over 4 years old so if there was going to be a community of users, I think it would have happened by now.

but also having the versions decoupled there could be useful.

Could you say more here? In my mind, there is little value to supporting a range of dependencies for something like xpublish.

Maybe make a fork that we maintain, and if they respond you could just PR back in, or properly diverge?

Open to this but it seems to me like its more work than its worth (to me). I've reached out to the authors of the package through various channels but they all seem to have moved on from Meteo Swiss.

[xaviernogueira]

@jhamman no problem! Been busy with the new job but now that I have my grounding I am looking to get back involved a bit on the open-source side.

You are right that if there would be a community, it would exist already. OpenDAP is pretty niche.

My only thought on the versioning, is that in principle, a protocol implementation's update cycle could be meaningfully different than a xpublish router. The OpenDAP implementation is not 100% complete, as it represents a "minimal implementation".

Example: Let's say we want to update the OpenDAP implementation to support more of the spec's endpoints, we would want as many users to have that upgrade as possible. But let's also say in the future there is a new version of pydantic or xarray with breaking changes. In such a case, someone using an old version of xpublish due to their projects constraints would not be able to use the new endpoints.

TLDR: Having to upgrade xpublish (which in the future could include packages with breaking upgrades) in order to access updates to the protocol implementation is not ideal, as it forced people to update more packages than is strictly necessary (and perhaps make code changes).

That said, it's a niche project, and not widely used. So it's not life or death. But that is my view.