January 26, 1987 11:39:13 am PST
Thrush
Not only should ChangeState and Progress detect calls left in the initiating or notified state, but also there should be a time-limit on how long these states may be allowed. Perhaps combine with present deferAnswer timing? Yup. Progress should look at whole list of convs, make sure max one is in a state demanding conneection to a voice terminal, zap the rest. Finally do it right, that is. Do same thing for LarkTrunkSmarts, possibly BluejaySmarts. Not clear anything is needed in FinchSmarts -- either the user can zap manually or roll back or it doesn't matter.

January 14, 1987 11:22:48 am PST
Thrush
It's possible to leave Larks permanently in bad states when Finches screw up. For instance, if you run a buggy Finch and then try to make a call, it can leave your Lark in initiating state, which doesn't prevent you from making FD calls, but does prevent BD calls due to FD/BD conflict comparisons. What causes FD initiating thing to get forgot by the Finch, even though it stays in the fray. Have seen a similar "notified" situation. Need some sort of timeout on those states? Blagh. Looks like currentConvID can get cleared while one is still in the initiating state, or maybe there are situations where it never gets set but the initiating state isn't left anyhow. Probably requires that Finch do the initiating and that it fail without appropriate action in the process, but sheesh.

January 13, 1987 11:50:58 am PST
Thrush
There are situations which leave things in a strange state. For instance, killing a Finch when it doesn't have a Lark doesn't idle the Finch in the conversation, even though there's no one to splice. So a party remains in notified state and leaves conversations around. Harmless enough, but annoying. Since can't select conv, there's no user interface way to grab them and get rid of them. They don't splice back in when Lark comes back, neither. Not sure how to characterize that, but try.

December 22, 1986 2:31:45 pm PST
All
Must now once and for all decide how to handle multiple calls in LarkSmarts; once past the notification hurdle, that is. Must somehow assume that it's OK to be in multiple conversations, and that somebody else will take care of the adjudication (like multiple-activeness). Just finish the inactive/mustActive .... state table and hope for the best. Each progress opportunity should scan all existing conversations and decide what to do about each. Use some switching notion to determine which one (ones in the funny-conference case) is connected to the hardware. Think about something that refreshes the list of convs. in a smarts from the Party, or something. Somehow they should come to look like caches, not different truths. Recent thinking: some conversation states (reserved, parsing, ringing, active) require connection to the hardware, some don't (notified, initiating, inactive). LarkSmarts should be conservative about proposing new conversations (Finch needn't), but liberal about rejecting new attempts to require the hardware when previous conversations have already succeeded. Such an attempt is an error or is due to a race (stateMismatch doesn't apply across conversations).

Finch code guaranteed to fail

Finch: could support talker. Or at least a simple "send this string to this other Finch user" function. For use when you don't want to intrude, but do want rapid transmission. The phone could beep, if that bit could be got right.

Could do the same with short recorded messages. They wouldn't be kept or have anything to do with GV. Only if the other party's got VoiceDB stuff running kind of thing.

Could annotate documents with synthesized voice or just with other structured text.

Could support refs in documents to unnamed but large and slow-changing things other than voice. Like figures for a paper, which are replicated in each version.

And so on.