Updates: Patches?

[herojoker]

To reduce server load creating patches (instead of having to download the whole package again) might be quite useful!
I assume you use a versioning system, so creating patches (even on the fly, at the first request) should be easy.

[jgpaiva]

I think that'd create extra problems: if someone doesn't download every single version, that person would have to download a few patches, complicating the instalation process.
Also, only a few people download every version, it doesn't compare to the number of people who download the software for the first time (at least, that's what I think! )
It would make it easier for us, the ones who download it on every version, but I don't really care for a few MBs a day, and I think it wouldn't compensate the hassle it'd be for mouser to create several packages, etc.

[mouser]

It's not technically that hard to do.. but it would involve a lot of extra work on my part building these different ways of getting the program and uploading the different files.  If i didn't have so many different programs i maintain and didn't update as frequently as i do it might be something i'd consider, but as it is now it's just not something i plan on.

[herojoker]

@jgpaiva: That's why I mentioned automatic patch generation... Person A has an old version for which no patch exists yet, so it's just created on the fly with help of the repository. It should just be a binary patch! You don't even need automatic building[compiling] here!
I now see that there isn't even a (classical) repository needed (like SVN or CVS) but only all previous FARR versions. One could also limit the number of previous versions to, let's say, 20 or so. All older versions cannot be patched and a complete download is needed.
Additionaly all old patches might be deleted, so there are only 20 patches online.

To sum up the scenario:
First possibility: The server contains all FARR versions, if a patch request comes in, the desired patch is (if not already there) created (automatically; a binary diff?), the url to the patch is returned.
Second possibility: The server contains only a certain amount of FARR versions and all patches from older version to the newest (or to some major/security/... builds) are stored (created offline, then uploaded by mouser?), if a patch request comes in, the url to the patch is returned.

Of course mouser could freely change the parameters I used in the second possibility (and there may be many more ways to do it).
I think the latter way is not so difficult to do but the first one is quite flexible 

@mouser: Oh, ... yes. It would definitely need some changes But it could also simplify your whole work process.
I have automatic patch generation (in the 2nd case) and uploading, and an automatic post in the update thread (based on the changelog) in my mind... Writing a program which does this could be used for all your apps!

The first case would reduce the work you have to do because patches are created on the server side (don't know your infrastructure).

[lanux128]

the differential patch idea is good since we have the DCUpdater to check and download the new & changed files only.

[herojoker]

Aah, you just mentioned the obvious third possibility:
Complete files are downloaded if they are new, but only new ones (I had only direct (binary) patching of the files in my mind before).
This process can be simplified if the patches I mentioned before are replaced by simple text files containing the files changed or added.
For example:

patch_2.22.01-2.23.01.txt:
* changed.xyz
* anotherchange.xyz
+ file1.new
+ file2.new
- removed.foo

These files could then be downloaded from a certain directory on the server.

Of course there are again many ways to build the whole system:
1. Patch files only from one version to the next one
2. Patch files created on demand from arbitrary versions to others (only one time for each patch)
...

If the first way is used the updater should first collect every patch file from the current version up to the desired target version (cumulative; skipping doubles) and then do the work. This way a patching cascade is avoided and also the server load is not so high. Only a bit space is needed for all the different versions. If mouser installs a versioning system even this is not a problem anymore (because internally only diffs are stored).

Perhaps a mix of the download-whole-updated-files approach and the download-binary-patches approach may be useful, because I guess it is the FindAndRunRobot.exe which is updated most oftenly and this file is quite big (currently 3.81MB), a binary patch will be probably much smaller.