Talk:Software Update
bsmedberg says: Why is the update a separate executable? What we would need to add to xpinstall is
- Binary-patch functionality
- Ability to do the xpinstall at shutdown/startup (not now)
Since we're planning on coding these features anyway, let's do it right! I can't see that it would take a lot more time than creating separate update executables for each update.
darin: There is a strong desire to avoid the complexity of xpinstall. We only need the ability to add, remove, replace, and patch files, and that can be done simply and reliably without xpinstall. Most of the complexity of software update is not addressed by xpinstall. The separate executable idea was intended for two reasons: 1) no need for the user to download the update utility until they need to update their app, 2) the updater would be very small, and 3) we might want to change the updater in the future.
Silver says: on NT-based OSes, you can at least rename files that are loaded as part of an application. This would allow you to rename existing, in use files, put down the new ones, all with Firefox running. Then restart it, and clean up the old ones in the background.
darin: There's no real benefit to this approach since users still need to restart Firefox to get the new version. It is easy enough to apply the changes between the time Firefox shutsdown and restarts from the point of view of the user. We can easily make the updater show a progress meter, and that should just do the trick.
Comments from bsmedberg: are we sure that the mozilla mirror network supports byte-range requests properly? Is there some other way to gate bandwidth?
darin: Yes, I have tested this out, and it seems to work. The only problem is that the various web servers do not all compute ETags in the same way, so we cannot issue If-Match requests, but that should be okay since the URLs of the files being downloaded should be sufficent to make the entities unique.
justdave: NO!!! The primary mirrors support it, but there's no way to guarantee that the secondaries do, and the primary mirrors don't have enough available bandwidth to support every Firefox user downloading at once when we have an update. Anything the update service downloads needs to be obtained via our download redirector on download.mozilla.org, so the bandwidth gets distributed to all of the primary and secondary mirrors according to who has bandwidth available.
darin: I think you're worrying about something that we can easily solve. Fetching the data via redirect is not a problem for this system. The idea here is that we will try to fetch the files in small chunks. We need to worry about all of the firefox's trying to update themselves, but we can be smart to ensure that they are balanced out. The download redirector could even return an error if the load is too high. Then the firefoxes will wait until some timeout before trying again. Are you sure that the mirrors do not support byte range requests? Even very old versions of Apache supports it for static files. Are you concerned about using HTTP instead of FTP?
Comments from bsmedberg: We should think carefully about how we handle these signatures. I presume we want mozilla updates to be signed *by mozilla.org*, not just signed in general. How do we identify which cert/certchains are appropriate?
darin: I'm not sure. I suspect that dougt will have some good ideas about this problem.
Comments from chofmann: capturing some things from a discussion this morning...
-how to deal with situation requiring multiple updates. options are to apply patches in sequence possibly running browser between installations to sanity check, or not. or maybe just initially force multi patch users down the full update path.
-experiance shows we need to have a pretty exhastive list of OS combinations to test against so we capture behavioral diffs between win98, win2k, xp, osX releases, linux distros, etc...
-roll back: details to work out about that to do when a roll back situation is encountered. maybe try again, or roll from patch to full upgrade.
-look at options for compression of the packages:....