Discussion
The implementation of voice ropes consists of three packages: Bluejay (the repository for voice files), which stores its files on a separate, specailly formatted disk; the Voice Rope implementation itself, which represents its information as a Cypress database backed up by logs that are also written on Alpine (??); and a client-program package. Here we'll discuss only the first two.
Bluejay: A hang-up to higher-level designs has been the rigid tune structure. A present-day Bluejay Tune is given a name that is an index into a fixed-size table, presently around 3000 entries. One is therefore obliged to practice tune conservation and complicated tune management. What we'd actually prefer is that utterances just be assigned regions in a large virtual memory. Since more than one might be being recorded at once, that is impractical.
We intend to revise Bluejay's directory system so that it will generate UniqueId's for tunes from a large (48-64 bit) address space, as it is recording new ones. A tune can now be an utterance, or (at the discretion of the client (voice rope implementation)) a set of utterances. But it's considered OK to make it a single utterance. It is now more likely that entire tunes will become free simultaneously, so that complicated internal reallocations are not necessary. So the indexed file directory will now have to be hashed, and will have to be able to be variable-sized. If this proves difficult at first, we'll fake it with a hash-table implementation on top of the present tune-structure -- 1:1 with recorded tunes.
Now a tune can easily be associated with a single encryption-key, so we'll store it in the leader page for the tune. We'll also store a creation time, and a creator RName. Possibly also a length.
Voice Ropes: These are stored in Cypress. Represented by entities whose names are their VoiceRope ID's. Described by relationships in the voice rope relation, sketched below.
We've made one significant decision about voice ropes: their representations will be flat, rather than hierarchical. Not quite true: they will always be described by a one-level hierarchy. This means that the description of a voice rope will be a linear list of [TuneID, TuneInterval] pairs. This avoids having to wander around in Cypress to get the description of a rope is the result of repeated editing. It will be cost-effective only if editing does not produce ropes that are too complicated. Our preliminary predictions of how applications use these things indicate that this is a pretty good bet.
During recording, the system can use some default minSilence value to produce a set of intervals for an utterance -- corresponding to talkSpurts -- rather than a single entry. This will make subsequent DescribeRope operations more efficient.
Interest: We toyed with combining the representation of voice ropes with the representation of the interest by clients in them (needed for goodstuff retention during garbage collection); this would require producing a new VoiceRope, containing a copy of the description of the old one, each time someone new expressed interest in a rope. Since we want to be able to copy a file containing VoiceRope references, then indicate an interest by that file in the ropes without changing the contents of the file, we chose to stay with a separate interest relation.
Tuples in the interest relation allow a client to associate with a VoiceRope a unique identifier (an InterestID), of a specified InterestType, along with an optional timeout. As long as this tuple exists, the associated voice rope will not be collected. There are three ways for an interest tuple to go away:
1. Explicit deletion by client via ForgetAbout.
2. Expiration of optional timeout.
3. Disappearance of the referent of the associated InterestID. (Discussion continues)
In a system like Walnut (with voice), there is sufficient control over create, copy, move, and delete operations that a client-controlled management of these interest tuples is feasible. Once we start dumping VoiceRope id's into Tioga files and start copying the files around, all bets are off. We don't want to saddle our users with too difficult a management job. So the idea is that for uses of this type we use a special InterestType ("File"), then supply a fully-specified file name (possibly time-stamped as well) to an IFS or Alpine file as the InterestID. When the garbage collector runs, it assumes that if the file no longer exists, the creator is no longer interested.
One can now copy a file with voice ropes in it. The copy will be able to refer to the contained ropes without danger of their disappearing until the original file (the one with the back-reference in its interest relation) has gone away and the garbage collector has noticed. To hang onto the references longer, some program or other needs to make a new interest entry citing the new file copy.
FS.Copy could eventually pick up some smarts about the files it's copying -- Fiala needs this ability to deal with compressed files, too. In the meantime, the temptation is to change SModel so that as it puts a file on a file server, if it has voice in it (a property of the root node) it will update the appropriate interest relations. (Probably need a property parameter that suppresses this automatic update of interest.)
Logging: (Early thoughts) The VoiceRope server needs to keep a Walnut-style log of all its operations. It will have to be segmented so that nearly-full logs are not included in expunge operations -- like current Walnut design. This log is for reliability. (It can be kept short if we also back up entire segments once in a while, but no present plans.)
It appears there will also need to be a log at least optionally maintained by each client. This will allow update requests (to the interest relation stuff, anyhow) to be made even when the VoiceRope server is down. Lets Walnut and SModel proceed.
This can be made less onerous by developing a semi-automatic logging technique based on "pickling Apply"s -- storing procedure names, parameters, and possibly return values based on Cedar AM or Lupine-like automatic processing. So logging is made simply a matter of some simple initialization, then making the logged procedure calls in a peculiar way.