<> <> <> <> April 6, 1987 7:57:46 am PDT Thrush Testing new LoganBerry database wrt Thrush. Check out LarkSmartsInitImpl.Register to see if we really get RNames of the form Swinehart.pa.lark in. Consider LarkC program to remove that nonsense. Or maybe a change to Vitae? March 6, 1987 10:59:07 am PST April 6, 1987 7:57:39 am PDT GVNames Notes on conversion to LoganBerry: Rname: primary key for both connect: BluePages, updated through GV query when not there already (think about that, dirty.) dotune: BluePages FNm: WhitePages, then BluePages (there if Name is there) FstNm: WhitePages, then BluePages (there if Name is there) instance: BluePages interface: BluePages key: BluePages larkhost: BluePages mode: BluePages Name: WhitePages, then BluePages OfficeNumber: WhitePages, then BluePages (there if Name is there) program: BluePages RgNm: WhitePages, then BluePages (there if Name is there) ringtune: BluePages workstationhost: BluePages Yes Consider lower-casing all keys, afore it's too late. No Consider putting FNm, FstNm, RgNm in BluePages corresp. White pages entries?? Pro'ly not. Yes Have a mapping file, possibly compiled, for determining where to look for efficiency. Yes Have a different database for actual Grapevine lookups. RedPages or something. Always encrypt that connection, send the keys as now, use only for authentication and connection-determination. In light of that: rname: primary key for both connect: RedPages, updated through GV query when not there already dotune: BluePages fnm: WhitePages, then BluePages (there if Name is there) fstnm: WhitePages, then BluePages (there if Name is there) instance: BluePages interface: BluePages key: RedPages larkhost: BluePages mode: BluePages name: WhitePages, then BluePages officenumber: WhitePages, then BluePages (there if Name is there) program: BluePages rgnm: WhitePages, then BluePages (there if Name is there) ringtune: BluePages workstationhost: BluePages Steps to conversion: 1. Implement simple GetAttribute, GetAttributes functions. Leave out consideration of authentication, GV caching, or timed values. Omit auto-choice of database, choosing one only. 2. Implement SetAttribute, omitting auto-choice, including way to specify database, plus default (partially from TiogaVoice implementation). <> 3. Implement the auto-choice stuff. Merging stuff was abandoned -- attribute-list queries must call once for each database. 3.4. Implement the automatic choice of database for SetAttribute. Done, but won't work for whitePages, and is sort of useless for red. 3.5. Implement the uniqueness of the host secondary keys, any other consistency requirements. 4. Worry about timed values. Won't work for keys (but won't be caught either.) Main value is "#"; previous main value, if key is x, is stored as untimed.x, and timed value is stored as timed.x. Main value can be returned to main key whenever the code would like to do so after the timed event has timed out. Works very nicely. 5. Implement authentication and GV updating. 6. Decide whether to do any value caching at all. Would like some notion of a set of atomic queries, whence it's OK to retain the prev. value. One entry? Several? Consider settling for using a cursor, remembering it and the key that generated it, and not releasing it until the next one needs to be generated. Don't do it at all, for starters. 7. Decide what to do about security. 7.2. Decide what to do about prefix searches. Delay. 7.4. Decide what to do about relationship to tdir. Delay. 8. Load files and the like. Consider renaming the interface before it's too late. NameDB. 9. Implement some basic commands to replace GVMode, GVDebug, GVOperate. Others must be handled by diddling the database by hand via LoganBerry. LarkDebug, LarkOperate. NameDBDetails? Concatenate $white, $blue, and $red, removing $rname from all but first found. Then print them out -- look for help from LoganBerry. Strange states: 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- not-yet-implemented-side-conversation-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 firm about rejecting new attempts to require the hardware when previous conversations have already succeeded in acquiring it. Such an attempt is an error or is due to a race (stateMismatch doesn't apply across conversations). 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. 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? 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. 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. 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. March 9, 1987 3:25:26 pm PST Thrush Beep on hangup is a frequent, annoying occurrence. It represents an avoidable race, I'm sure. Scan old notes for what causes it. February 10, 1987 8:36:59 am PST Thrush Add some simple statistics. # total calls, time started, # trunk calls, # service calls (by service?), # attempted/completed, current # calls in progress. Think about a (temporary) display indicating who they are? January 19, 1987 5:43:15 pm PST Thrush Redesign decisions about when to cancel visiting. This can be deferred until after release, probably. <> February 12, 1987 7:48:39 am PST All Consider the LoganBerry conversion for NamesGV (all of it???????) February 10, 1987 6:04:04 pm PST VoiceUtils NamesGV.Authenticate should compare keys before returning. Also NamesGV interface (and all other RPC interfaces) should allow for secure communication, and demand it for updates. The allow-for part has to be done at a time when the server is being upgraded. Dont' do this if you're going to replace the whole thing with LoganBerry, of course. February 11, 1987 7:36:01 pm PST All There isn't a version-numbering strategy for any RPC interfaces except for the actual ThParty/ThSmarts ones. Probably should be. December 29, 1986 11:34:39 am PST Thrush/Finch Synthesizer playback very flakey. Sometimes the utterance is cut off, as if it is being played before the connection is fully established. Possibly should play the KeyDistribution trick with a bogus key, just to synchronize? Other times it doesn't play. Situation is confused by same-machine RPC failures between Finch and Thrush on same machine. Need to wait for more standard test, and until Finch handles timeouts and failures better, before continuing this investigation. November 26, 1985 4:09:21 pm PST Thrush P: showslower: no good methodology for killing and reregistering Bluejay parties -- automatically, anyhow. April 21, 1986 3:40:20 pm PST Thrush Service larks (T-T-S, radio) are defenseless against back-door callers (except by not plugging in the back door, of course). There's no way to detect when the other party hung up. No dial-tone or click-detection, and anyway, in the case of the radio server, the hybrid bounce from one's own noise would drown out any ability to do it. Consider watchdog timer thing of some sort, not sure what, to deal with this. Should this be disallowed and prevented? Best thing to do is disallow connections from back doors to services? How about all the things people want to do about recording calls and the like? <> December 22, 1986 2:11:42 pm PST Finch error reporting in Finch needs to be reanalyzed. For instance, when calling self, complaint is "no valid party found", accompanied by the "philosophical" comment passed on from LarkSmarts. June 22, 1986 9:07:53 pm PDT Finch Conversation ID management in Finch is a total mess. Everybody seems to have to know who's who. Some don't. Idea: have a notion of "the connection to the voice service". Seldom valuable to have more than one, and in those cases we'll be controlling it. Use it if it's around. Inactivate it when not in use (rather than shutting it down in Lark) and Zap only after a while. Can inactivate when receiving incoming calls, etc., too. Maybe Flush and restart. Food for thought. December 23, 1986 3:49:42 pm PST Finch Many to/from confusions about who's calling whom, esp. BD incoming calls. February 17, 1986 6:08:55 pm PST Finch 5. Finch, when told that self is no longer poaching, or when it drops out, should unselect the present conversation and either make a separate conv log entry (not all entries need be conv Descs any more, could have entry for each connection and disconnection!) or record dubiousness in last entry. Mostly won't know about these situations, because server will forget about us. How to tell when one has been hung up on? Need a function in FinchSmarts in case there's still communications. Does this beat against the Queue flushing that's done (is it?) when a Smarts goes away? Maybe should be flushed only if communications fails. This might happen when a new poacher comes along. <> <> FinchToolImpl.CheckActive: PUBLIC PROC[handle: FinchTool.Handle] RETURNS[active: BOOL_FALSE] = TRUSTED { <> IF handle#NIL AND handle.finchActive THEN RETURN[TRUE]; StartFinch[]; RETURN[handle.finchActive]; }; tries to return NIL.finchActive if Finch not active when called. Looks like StartFinch was supposed to fill in handle. Breaks because even if StartFinch produces a handle, if there wasn't one before there still isn't. So the "Phone" command, issued before Finch has been manually started, fails. <> July 15, 1986 7:14:11 pm PDT Thrush/Finch Polling doesn't scale, if it's the primary means. But it is necessary to catch deaths that occur during hiati in communications. Right now there's no polling at all in the voice system. And there needs to be. Alternative: make it always harmless to have a hiatus; for instance, Finch can catch up with the call log when it and the server have been out of contact. January 19, 1986 3:42:40 pm PST Finch When Finch drops out, most recent conversation log entry remains selected. Should probably put distinctive value in there and deselect. If Finch restarts during same conversation, either compare convID's or just start a new entry. <> November 26, 1985 4:09:21 pm PST Finch Finch checks in once in a while, re-registers if gone. June 11, 1986 6:19:11 pm PDT Finch Maybe don't have to analyze error situation in Thrush, but Finch is truly a mess, and adding side paths for VoiceRopes makes it worse. Have really got to get that under control. Monitors, when and where to complain, and the like. Look at VoiceDB stuff for some guidance in options of who reports and all. May 4, 1986 11:49:14 pm PDT Finch Need specific tests in FinchSmarts for $voiceTerminalBusy, and a better response in error log. "no valid party found" should be replaced by the comment if there is one on failure. <> December 18, 1985 11:21:07 am PST Finch The error reporting/management in FinchSmarts is as confusing as ever. Some things are reported as problems directly by FinchSmarts, others in a form of conversation state reporting to FinchSmarts client. Most of the error checking in the present rendition is minimal, awaiting a thorough review. FinchTool will just have to cope. <> <> February 4, 1987 6:28:31 pm PST VoiceUtils Document the interfaces that are available in VoiceUtils. People might find many of them useful. January 19, 1987 5:42:26 pm PST All Document recent database additions somewhere, like $multiring and $deferanswer. June 26, 1986 9:33:49 am PDT All Document briefly the list of recent improvements. April 28, 1986 1:18:55 pm PDT DOC Document new meanings for **7, **8, **9, *0name# => *name#, new monitor-mode stuff (hard). <> <> <> <[]= rather than [] = ; now all the parties and state to a conversation can be found by using the conversation as an attribute! The other searches are fast due to $Party attributes and so on. Sounds like a winner, but wait.>> June 19, 1986 8:51:48 pm PDT Thrush/Finch Consider ThParty call that returns updated ConvEvent (self=other) to update state. Then stateMismatch can be upgraded in a loop. Consider NoteNewState change so it never does anything directly (never does, anyway, except during notification, which has to be the first we've heard of the event anyway. Can the WhatNeedsDoing stuff be pruned further? <> <> June 17, 1986 10:45:54 pm PDT Lark Think about having Zap clear out voice-related sockets somehow, to save on the number of necessary calls. Probably the non-zapping version was trying to save on calls. There can still be a 400A occasionally, when things go wrong. Rebooting will usually be OK in these situations, though. <> August 9, 1986 3:22:26 pm PDT Thrush Design methods for recording calls, playing back stuff to all/chosen parties. Needs flexibility, needed also for radio broadcasts and such, for one-way traffic on some links, dynamically determined. June 28, 1986 10:37:22 am PDT Thrush Longer-term solution to the ringing-once-per-cycle problem: Callers who can't get through immediately should be able to persist: must be able to recognize rejection states from callees. Callees willing to allow calls to persist and even eventually succeed must enter states they can get out of. Maybe inactive is good enough? Callers, similarly, when they want to persist, must enter states they can later get out of. Error may work, except for the special treatment of notReallyInConv that might conflict. Now things like increasing the priority, if reported as events, could allow real-time alteration of the treatment of existing calls, and like that. June 26, 1986 9:32:57 am PDT Recorded voice Doug or I has to decide how to use the ambient-level stuff, experiment with thressholds. It is now possible to set the silence threshhold for a Lark from Thrush, by the way. February 2, 1987 10:55:34 am PST All Provide facilities for determining in Finch if the Lark is up and functioning. Actually, GetParty["Self", $telephone] should do pretty well. Then need better control over busy-handling for the simple procedures like TextToSpeech[...]. Definitely need some workstation-side packaging. This is in response to Fiala's complaints. January 30, 1987 1:58:25 pm PST BluejaySmarts Doesn't have the corresponding notion of Fail that Lark does. When $noSuchSomething comes up, it's not likely that the smarts will even clean up the conversation, let alone drop out and start a new one. This can probably be deferred; failed recording parties represent serious problems that should be found and fixed. January 28, 1987 7:54:54 am PST Thrush nb and reason should be merged. Makes it harder to index things by reason, but could use a hash table for that. December 23, 1986 3:37:38 pm PST All StateInConv -> ATOM, and find another way to do state comparisons when necessary. Allows more flexibility in assigning new states. Make sure there's a way to find all of the assigned values, though. December 23, 1986 3:38:46 pm PST All Add $monitored state: like $inactive, but party doesn't really intend to come back -- wants to observe other transitions, though. Good for Agent stuff? Can come back as long as somebody's still in the conv., but should go away if everybody else is either $monitored or $idle. December 23, 1986 3:48:46 pm PST Thrush Option: don't override volume control during ringing; for development. December 23, 1986 3:49:01 pm PST Thrush Program control over ring volume, better than now. December 8, 1986 6:45:51 pm PST Thrush key distribution: not satisfied with how it's done -- the report when all reports done thing is a kludge. Should distribute keys, wait for input events (from larks) or equivalent, send in a complementary report which counts. Maybe the original report can contain a handle on the service that's updating the keys and one can communicate directly with it. Anyway, could then remove the hairy report stuff from Thrush. August 14, 1986 11:23:03 pm PDT Thrush Need a way to register behaviors with LarkSmarts. Could be through additional smarts mech., but they're gone. In any case, things like call filters and so on should be handled that way. Prose specials, all that sort of thing. Too much is done in line. General registration mechanism. Extension of service registration? Don't know. Not an issue if Finch is supposed to do most of the hairy stuff. March 14, 1986 6:59:43 am PST VoiceRopes Should Tune-archiving information be written into Tune headers, along with keys, voiceFileID's, creators? March 2, 1986 11:43:27 am PST VoiceRopes If one records a long rope, one might want a way to checkpoint the partial results, or at least record the existence before it completes/shortly after it starts. Also, want unvoice-activated terminations ---- recordings that stop when the speaker stops for long enough. March 2, 1986 11:44:04 am PST VoiceRopes Silence threshhold is something Bluejay could pay attention to on recording, independent of Lark choices. February 22, 1986 3:48:57 pm PST Thrush Rework all the user profile values, combine where possible, use Intervoice prefix February 4, 1986 8:37:38 am PST VoiceRopes LoganBerry calls from VoiceDB are not encrypted (!!) January 27, 1986 7:03:14 pm PST VoiceRopes Walnut forwarding needs to have hooks allowing programs to run. For instance, the VoiceFileID's of the forwarded message need to be able to be substituted. We also need a way to recopy (forward assuming you're sending it again.) December 18, 1985 12:04:27 pm PST Thrush I'm no longer convinced that queueing is needed in the Smarts at all. Probably one for the Lark keyboard, just to keep the characters flowing, but otherwise, now that conversation state is reported back for each call, it may not be necessary. Seems artificial every time I queue something. WaitForActive also has to do something like that, but a simple condition variable thing might well be good enough there; Progress is reported in its own process. November 26, 1985 4:09:21 pm PST Thrush Make sure there are routines for setting conversation attributes (subject, urgency, ...) after initial creation. <> <> November 26, 1985 4:09:21 pm PST All Logging, statistics, performance measurement. <> December 18, 1985 11:47:13 am PST (optional) All progress report (pd.reports) output has been removed from both Thrush and Finch. Consider what's needed when thinking about statistics gathering, logging, error management. January 11, 1987 2:57:09 pm PST Thrush Lark buffer connections now complicated enough that a differential approach is the desirable way to avoid unnecessary break/make sequences. Just the way hardware switching is done now. December 22, 1986 1:49:02 pm PST Thrush Suppose Party A alerts parties B and C, each of which have the same voice party. This is a case with the same problems as the narcissism case. Can it arise? December 18, 1985 11:52:35 am PST Thrush Think about whether a common set of smarts implementations at some level would make sense. <> August 12, 1986 6:13:17 pm PDT All Idea: many smartses seem to need (1) notification when something happens and sometimes (2) a way to wake up once in a while even if something hasn't happened (most recent example: ringing for only a while after somebody else has answered, and in fact somebody else might have answered first. Can we do anything at ThParty level to regularize this? Notify in time t would be fairly easy (all or just me!). Would be nice to have some value that would travel across and back without damage, so that the notification could include, for example, a call-back proc!!!!! See, the trouble with waiting for some event is the standard problem with waiting for two kinds -- user input and the other kind. Could we just do smarts behaviors all by Progress events? So that all smarts actions are defined by stream of such things. Like lists of ref any or something? Then with the timeout, we've got something manageable, sort of. What is then the relationship of this to what WS clients of smarts do? Have to think this out. In meantime, just do something. June 2, 1986 7:48:16 am PDT All Think about adding a local interface record to the service registration stuff. All these interfaces must be of the multiple-import type, just to avoid hassles. Document that, too. <> April 21, 1986 3:40:20 pm PST Thrush Pity DTMF detectors also don't do dial tones, busy tones, and the like. Maybe some do. <> <> <> <> <> <> February 23, 1986 1:49:37 pm PST What would it take to make BD all analog again? February 23, 1986 1:49:54 pm PST "who is talking" feature during teleconference, other high-performance stuff based on voice content; how to control? Control over who is talking, meets Stodolski's requirements. <> December 19, 1986 1:45:04 pm PST Finch indicate real names of people, rather than RNames, in Finch log. Real names on screen, both names in permanent log? December 23, 1985 1:37:37 pm PST (optional) PartyInfo called in FinchSmarts uses nameReq: $description to get most human-sensible description. Then FinchToolImpl.ReportConversationState has to strip off extraneous stuff for calling/called party fields. nameReq: $current would usually be a better approach, but that would mean calling PartyInfo twice or convincing it to supply two ropes sometimes or something. Worth thinking about; still not there yet on what Smartses need to know. <> November 26, 1985 4:09:21 pm PST Reason, comment should be part of credentials? Seems to need to be replicated, too. Sigh. <> November 26, 1985 4:09:21 pm PST Determine degree of authentication possible for each type of registrant. Add data structures necessary to reflect authenticated/not. Use RPC-provided information where possible to be sure of authentication. November 26, 1985 4:09:21 pm PST In any session, authentication of a GVNames cache password should be renewed by client call supplying password. Present interface can handle it, but it's not presently done.