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.

Profile Structure

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.

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
this:
- c:
  - Program Files
    - Netscape
      + Communicator
      + Communicator5
      - Users
        phil
      - Users5
        phil

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.

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.

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 files

We agreed that there will be one Javascript preferences file, and it will be called prefs.js on all platforms. Some items which are prefs in 4.x will move into a style sheet for 5.0. This mostly means window size and position, column widths, etc. Anything which is editable in the prefs UI, or which needs to be locked by Mission Control, can not be moved into a style sheet.

Newsgroups

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.

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.

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.