Refactor to support new file service about ems-file-service HOT 3 CLOSED

Thanks for this. I keep coming back to this when I run into questions and I find the answer is almost always there. You've given this a lot of thought!

Do you have any recommendations for numeric IDs in the data file names? For example, if we have a breaking change to the World Countries GeoJSON file, how should we generate the new file name? Is it as simple as having world_countries_1.json and world_countries_2.json?

Or should we look at having a short UUID like world_countries_5fege.json and world_countries_e43f3.json.

Either way each version's manifest file would have to know which one to use as part of the manifest generation process.

from ems-file-service.

I guess we should have "primary versioning", e.g. world_countries_v1.geo.json, with the number incrementing only when the change is not backward compatible. The hashes would be a bit confusing, and are not really needed IMO for this case. We also have "legacy filenames", e.g. 298231987 -- which is basically just a copy of the v1 files to support legacy manifests. Note that when uploading extension-less files to the cloud, you may have to force the headers and compression on them.

from ems-file-service.

P.S. i guess the first version shouldn't be _v1 at all - makes it a bit cleaner. But not a biggy

from ems-file-service.