This is a very delicate line to walk. We want to silently update... yet not actually be silent. We want updates to take effect immediately... yet not require an app restart. You have provided some good ideas but, in practice, it can be difficult to close on a compromise that doesn't make some subset of players very upset, or expose a new class of complexity.
Chrom(ium) packaging and resource finding is different on each platform, which has implications for an update strategy. For the Mac, thomasvl is currently reworking the app structure, so it is probably best to wait for his work to complete before we make a proposal. jrg On Sun, Mar 29, 2009 at 2:31 PM, Jim Roskind <[email protected]> wrote: > Perhaps we need to think about how to encourage such a restart, without > being the traditional pop-up pain-in-the-er-um-rear. > Can we find real-estate that won't tend to detract from the ui to alert the > user that an update is pending? Perhaps atop a new-tab page? Perhaps an > extra entry ot the top-level "wrench" menu? ...in a different color near > "About Chrome"?? On windows, should we be alerting the user via the little > "updates are pending" dialog that Windows and others are using?? > > Can we make the update especially painless for users, by temporarily opting > them into to restore the existing tab settings, even if they don't usually > do so?? > > Can we do other things to make it easy, and obvious to encourage a user to > allow an upgrade? I don't think it is possible... but can we detect when it > would be a "good time" to upgrade, and just "help them along?" I suspect > that too much state would be lost (sign in, cookies, SSL session keys, etc. > etc.). Maybe we can "detect* that they are in a "very reproducible state" > and that "they are quiescent" and then do the update (perchance a large > percentage of users live in such states)?? Can we do some fancy > optimization to do most of the startup of the new version before we shut > down the old version, so the transition is super-fast?? > > It is clear to me that our wonderful work to "crash less" is working... and > greatly extending the time-till-update after the user has the downloaded > update on disk. IMO, delaying an upgrade is probably a Bad Thing (TM) for > the user (which is why we push out better versions)... but interrupting a > user's action is a very Bad Thing. Can we improve the compromise, and help > the user? > > Jim > > On Sun, Mar 29, 2009 at 1:25 PM, Erik Kay <[email protected]> wrote: > >> >> On Sun, Mar 29, 2009 at 1:02 PM, Thomas Van Lenten >> <[email protected]> wrote: >> > Most mac apps solve this by having the app exit as part of the upgrade >> > process, this way a new copy is launched w/ the new resources. >> >> yes, but this is the problem with silent autoupdate. We don't want to >> force the user to stop what they're doing when an update starts. >> >> Erik >> >> >> > On Sun, Mar 29, 2009 at 4:40 AM, John Grabowski <[email protected]> >> wrote: >> >>> >> >>> How will in-place updating work on the Mac and Linux? >> >> >> >> To be frank, we haven't solved this problem on Mac. >> >> Right now we're doing an rsync to klobber on update, which is fine for >> >> pre-dogfood. E.g. our "normal" Mac crash rate far exceeds any possible >> >> crashes caused by version mismatching in the 3 auto-updates we have >> sent out >> >> internally. >> >> Although we could load all resources on startup, that ignores one >> critical >> >> piece. Since renderers are separate processes and are launched >> on-demand, >> >> we would still have the problem of "old browser" talking to "new >> renderer". >> > >> > All platforms would have this problem if they don't force the apps to >> bounce >> > as part of the upgrade process, no? >> > TVL >> > >> >> >> >> I suspect we'll need to have either a versioned scheme line Windows, or >> a >> >> "complete upgrade" step on initial launch. >> >> jrg >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
