I was trying to do a review of the dump&reload: startup/installer functionality, but realized reading the code and the little bit of spec that exists that I don't think we have thought this through yet. See https://bugzilla.osafoundation.org/show_bug.cgi?id=8143.
The case where a user explicitly does a dump and reload from menu seems clear to me. Fully manual and all that. However, how are we supposed to handle Chandler upgrade? Let me give you an example... Two users share a Windows XP machine. Each has his own accounts, and the accounts are locked such that no user can see other users files. Even the administrator account can not look at another user's files. Let's say Chandler 0.7 has been installed as administrator in C:\Program Files. The two users share the executable, but have their our own Chandler profiles. One user stores the profile in a non-standard location, launching Chandler from a modified desktop launcher which passes the correct --profileDir option. Then comes along Chandler 0.8. One user starts the installer as administrator (so that it can write to C:\Program Files), and it detects the 0.7 installation. Now what? The installer could prompt to migrate data - except that it would not be able to migrate anything as it would not even have any idea that there were two users, less alone have any access to the profiles. The installer could prompt to uninstall the older version - except that this would then leave stranded any accounts that had not done a dump previously. So the only thing it can do is install 0.8. It must install into a different directory than 0.7 (see above). Installation done, the user logs in with their account. There are now two Chandler desktop icons - 0.7 and 0.8. The user launches 0.8. I think we should present the user with a dialog that asked something like this: (*) Migrate data from 0.7 to 0.8 ( ) Reload a dumped repository ( ) Clear repository ( ) Start new repository [OK][Exit] However, I see several problems. 1) How do we know to pop up that dialog? 1.a) Schema mismatch 1.b) No profile dir 1.b.I) How do we know the user is migrating and not just launching after a very first Chandler install? 1.c) Something else? 2) How do we figure out 0.7? 2.a) SCHEMA_VERSION could have the version in it. 2.a.I) But if there is no 0.7 installation left, or it is in a non-standard location, why would we even offer to migrate if we can't? 2.b) If we can find the 0.7 installation we could figure that out. 2.c) On some systems we could check the registry or some other installed applications database. 3) If the user chooses to start a new repository, where would it live and how would we know the location in further startups? Assuming migrate, then launch 0.7 with --dump option, which will bring up a simple dialog asking for dump location (default in profile dir), prompting to encrypt passwords if appropriate, and showing the progress of dumping. Should write the dump location in a text file in the profile. After 0.7 finishes, continue 0.8 launch by reloading dump file, then starting 0.8 proper. When the other user logs on, they'd do similar operation. They'd need to communicate with each other that 0.7 could now be uninstalled. This would of course not be as straight forward with true multi-user systems where the users might not even know each other. Does this seem like a valid workflow? Ideas about the questions? Reply-to: set to design list; please keep the discussion there. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
