Profile Migrationedited by Phil Peterson
On 3/17, a bunch of folks met about profile migration. We talked about who owns which files in the profiles, and how we're going to build profiles in 5.0. Here's a summary of interesting points, with open issues in red.
On the Mac, we have a useability problem which is that we put profile data in the System Preferences folder. This hasn't worked well because users think that anything in the Preferences folder can be deleted with impunity, and profiles certainly don't fit that description. Profile data will be stored in the Documents folder.Copy and Diverge
On Windows, we're going to create a new Communicator directory and a new Users directory, so the directory structure of a machine with 5.0 and 4.x would look like
- Program Files
We didn't decide anything about UNIX since we didn't have anyone in the room who had a clue about the right thing to do on UNIX.
We agreed that the minimum requirement for migrating profiles from 4.x to 5.0 is that we'll copy the relevant files from 4.x and then changes in 5.0 don't affect 4.x and vice versa. This is the minimum because we don't want 5.0 bugs to break 4.x users, and we think that having each version have its own files will have fewer bugs than if the versions shared files.Address Books
If we have time (hah) or lots of motivation, we could enable sharing mail folders between 4.x and 5.0. This has the advantage of smaller disk footprint.
I'd like to know what others think about this. It's a little bit of a reversal for me, since I thought we'd want to share mail folders. The time constraints and quality risk are convincing me that this is extra, and perhaps optional, work.
Another option is just to document how to share the folders using the "mail.directory" preference (if that's available in 5.0??)
We agreed that it would be helpful for the migration tool to offer to clean up some disk space in 4.x by deleting the old cache and summary files.
We need to refine our plan for address book migration. Our tentative plan has always been to offer a migration tool (not built into 5.0) which knows how to read 4.x address book files and generates MORK. This is certainly a big chunk of work, and it would make the import tool more complicated.Security
It was suggested that we create a new directory in the profile directory just for address books. Since there can be a bunch of them, this seemed ok to me.
The Security group needs to own upgrading any/all necessary security filesPrefs file
Here are a few mail/news-specific things that we didn't discuss, but are still important.
One of the most frequently reported problems I see with 4.x is that Communicator doesn't remember the newsgroups that users subscribe to, and they have to resubscribe every time they open the app. I think this is caused when users move their profile directory to a new location, but leave the FAT file pointing to the old location. I think we should consider breaking compatibility with 4.x (and 3.x) FAT files by storing relative paths instead of absolute paths.Multiple identities
The UNIX version never needed a FAT file since filenames can be as long as you want, but Mac and Windows did. Perhaps we can drop the FAT file for Win32 now, too, since Win16 is no longer supported. I assume the Mac soldiers on with its old filesystem, and need for a FAT file.
I assume we want to create more hierarchy in the mail folder for multiple POP accounts.Filters
The UE folks have a proposed filter design where all of the filters are editable at one time, rather than the 4.x system where there's a filter file for each scope (mail server, newsgroup, etc.). We need to work out how the persistence model for filtering works.