1) All of the existing tunes that have been used in voice mail must somehow be preserved.

2) The current interests that have been registered by WalnutVoice should be preserved.

3) Some of the existing tunes that we want to retain do not have interests registered for them, either because a user saved a voice mail message in Walnut when not running WalnutVoice or because the tune is valuable even if is not contained in any existing walnut message.

4) Some of the registered interests are undoubtedly for tunes whose messages have been deleted, perhaps because the user was not running WalnutVoice when doing a Walnut scavenge or because the server was unavailable, preventing an interest from being unregistered.

5) What do we do about the current VoiceFileIDs that are in existing Walnut messages? We should provide a way for these tunes to be played.

1) I will compact the current Tune databases and smodel them to [Voice]<Voice>Morley>. After this point, people should not use WalnutVoice.

2) I will convert each existing tune to a voice rope using the transformation:

Notice that the transformation is complicated by the fact that the TID has to be extracted. I still might be able to do it using the EditTool; if not, then I'll have to write a conversion program that uses the LBExtras interface to read and write log entries. These new voice ropes will exist in a separate log (OldTunes.DBLog) from existing voice ropes.

To simplify the conversion, I could use Length ← -1 and SL ← 0 -1 since all current tunes are used in their entirety. However, having the actual length and interval known is more efficient for voice ropes used in editing operations (it doesn't make a difference for playback).

Using the existing vid as the VRID will make it possible for users to play voice references in existing Walnut messages, that is, the current "voice file id" can be treated as a voice rope id and played like any other voice rope. The drawback of this approach is that vids do not have the same format as VRIDs. There is probably no concern about collisions, but it might cause problems for the existing voice rope code that expects to be able to extract a timestamp from the VRID. I'll have to check this out.

3) I will convert each existing entry in TuneRefs to a voice rope interest using the transformation:

This transformation will undoubtedly need to be done by a program because of its complexity. These new voice rope interests will exist in a separate log (OldTunesRefs.DBLog) from existing interests.

There is no compatibility problem creating new IIDs in this case since these IDs are used solely as primary keys; they should not really be used by clients for anything.

The class "WalnutMsg" will be used rather than "GVID" since other mail systems, such as Peanut, may need their own class of interests. The WalnutMsg class of interests uses the RefID to contain a Grapevine message ID; the gvID can be easily obtained from the rid in existing TuneRefs.

The procedure turns out to more complicated than this for two reasons. First, an entry in TuneRefs may contain several vids, whereas an interest can contain at most one VRID; thus, several interests may need to be created for each TuneRef. Second, the TuneRefs database contains entries with rtps (types) other than GVID, e.g. SysNoises, MIK, and TiogaVoice; each of these must be handled differently.

4) I will create a "temporary" interest for each existing tune that is converted in step 2 so that the newly created voice ropes will not be automatically deleted by the garbage collector. These interests will be of the form:

Note that these interests need not have a RefID. The garbage collector for class "OldTune" does nothing.

5) Users need to decide which of their voice ropes (that were converted from old tunes) they want to actually keep. Perhaps, I should write a program that each user can run to enumerate his interests of class OldTune; for each interest, the user can listen to the voice rope and decide yes or no. If the user says no, then the interest is deleted (and the voice rope will be subsequently deleted); if the user says yes, then the interest will be converted into a more permanent interest.

6) I will write a program that scans WalnutMsg interests and determines if the message really exists (by presenting the gvID to WalnutOps or some such beast). If the message can not be found, then the WalnutMsg interest can be deleted. Essentially, this is the garbage collector for class WalnutMsg. However, unlike most garbage collectors that get run on the server, each user would have to run this program on their workstation for their own Walnut database.

7) After a reasonable period of time, i.e. after users have had a chance to do step 5, I will add a GarbageProc that says that all interests of class OldTune can be collected. I will then run the garbage collector to delete unwanted interests, voice ropes, and tunes. (Note that I can run the garbage collector at any time after step 4, however it may not collect much.)