All of these reasons sound like votes for piggybacking on git. If github/gitlab/etc is used then it provides (1,2,3,4).
I did not mean to support plugin/extension-centric update sites actually from Icy. However, the other features seem desirable.
The hesitation is about whether swapping from WebDAV (who actually wants to keep using WebDAV???) to git will be particularly time/resource consuming. There are at least 2 ways of doing this:
1 - write it from scratch
2 - find the minimal modification that can replace webdav usage with git
Let’s ignore (1) because it sounds hard (at least relative to the immediate payoff).
db.xml.gz is just a file with a listing and a little bit of metadata about each file. This is easily supplied from a git repository (even by a raw file fetch of sth like https://raw.githubusercontent.com/kephale/fakeupdatesite/master/db.xml.gz).
The files supplied by the update site would be stored on
master or some other branch relative to the Fiji.app root directory.
I’m kind of convinced that download would be easy. What about upload? After skimming this JGit tutorial, it looks like adding files and committing to a repository is pretty straightforward as well. FilesUploader from imagej-updater is on the more complex side, but a good amount of that is overhead from dealing with WebDAV for locks and providing timestamping mechanism (which we get for free in git). Then digging a bit deeper it looks like a lot of the additional complexity in imagej-updater is about dealing with streams and pushing bytes; however, jgit would be taking over that logic.
My remaining concern would be about the conflict resolution logic. However, I think that does not even necessarily have to change because the minimal effort implementation might just reuse the current db.xml.gz system.
- Eventually we would probably find that db.xml.gz could be eliminated in favor of using the git history.
- Although we can already revert update sites using the db.xml.gz, reverting changes does become quite straightforward with git.