Talk:Software Update: Difference between revisions
ChrisHofmann (talk | contribs) No edit summary |
mNo edit summary |
||
| Line 6: | Line 6: | ||
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. | 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 | ''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. | ||
---- | ---- | ||
| Line 12: | Line 12: | ||
'''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. | '''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 | ''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. | ||
---- | ---- | ||
| Line 18: | Line 18: | ||
'''Comments from bsmedberg:''' are we sure that the mozilla mirror network supports byte-range requests properly? Is there some other way to gate bandwidth? | '''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 | ''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. | ||
---- | ---- | ||
| Line 24: | Line 24: | ||
'''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? | '''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 | ''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... | '''Comments from chofmann:''' capturing some things from a discussion this morning... | ||
Revision as of 18:23, 30 April 2005
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.
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:....