Proposal for conversion of Tunes to VoiceRopes Problems I see three problems in the switchover to the new voice rope server: 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. There is actually a fourth general problem: 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. Ah, and there is also a backward compatibility problem: 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. Current situation with tunes A sample entry in the current Tunes database (Tunes.DBLog) is the following: vid: 133 February 12, 1986 10:41:55 pm PST cre: swinehart.pa sta: 0 num: 112000 key: 30776043040B 10662037040B where vid is the entry's primary key, cre is the creator, sta is the start of an interval in the tune (every existing entry has value 0), num is the length of an interval in the tune, and key is the encryption key. Notice that the tune's id does not appear explicitly; it is embedded in the vid. A sample entry in the current TunesRefs database (TunesRefs.DBLog) is the following: vid: 133 February 12, 1986 10:41:55 pm PST tim: February 12, 1986 11:32:10 pm PST rid: pollez.pa/swinehart.pa $ 3#333@12 Feb 86 22:42:46 PST rtp: GVID cre: PolleZ.pa where vid refers to an entry in the Tunes database, tim is a timestamp for when this entry was created, rid is the entry's primary key, rtp is the type of interest (every interest currently has type "GVID"), and cre is creator. Notice that the id of the Grapevine message containing the referenced tune does not appear explicitly; it is embedded in the rid. Voice rope databases A sample entry in the current VoiceRopeDB database (VoiceRopeDB.log) is the following: VRID: Terry.pa#575904199 Creator: Terry.pa Length: -1 TID: 231 Key: 37013041536B 22771240323B SL: 0 -1 where VRID is the voice rope's id and the entry's primary key, Creator is the creator, Length is the voice rope's length (-1 means that the voice rope is a whole tune), TID is a tune id, Key is the preceding tune's encryption key, and SL is an interval in the preceding tune ("0 -1" means use the whole tune). There could be several sets of TID/Key/SL attributes for a voice rope that has been edited. A sample entry in the current VoiceRopeDBRefs "interest" database (VoiceRopeDBRefs.log) is the following: IID: Swinehart.pa#592116443 VRID: swinehart.pa#578564056 Class: TiogaVoice RefID: [Voice]Thrush>PoachNotes.txt!78 October 2, 1986 6:42 pm PDT where IID is the entry's primary key, VRID is a voice rope id, Class is the class of interest, and RefID is a class-specific indication of the actual container of the voice rope. An interest may optionally contain a Other attribute if needed by the given class. Notice that there are no explicit attributes for the interest's creator or timestamp; these can be derived from the IID. Plan of action I propose that the following actions be taken: 1) I will compact the current Tune databases and smodel them to [Voice]Morley>. After this point, people should not use WalnutVoice. 2) I will convert each existing tune to a voice rope using the transformation: VRID _ vid Creator _ cre Length _ num TID _ Key _ key SL _ sta num 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: IID _ cre# VRID _ vid Class _ "WalnutMsg" RefID _ 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: IID: cre# VRID: vid Class: "OldTune" 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.) ŒTuneConversionProposal.tioga Copyright Ó 1987 by Xerox Corporation. All rights reserved. Doug Terry, January 20, 1987 6:43:00 pm PST Ê€˜default™Icode™