Vital
Strange states:
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).
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.
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.
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?
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 12:13:32 pm PST
Finch
Keep conversation log on the server, so will record calls when workstation is powered off.
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.
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.
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.
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
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.










ŽFinchNotes.txt
Copyright Ó 1985, 1986, 1987 by Xerox Corporation.  All rights reserved.
Swinehart, February 3, 1987 6:25:35 pm PST
Polle Zellweger (PTZ) February 4, 1987 12:10:07 pm PST
Visiting and Poaching
Party/Smarts level redesign (who's in a conversation?)
Registration/Initialization errors and improvements
March 28, 1986 2:16:59 pm PST
Finch
Ken Pier found this bug:
Finch code guaranteed to fail
If not active, try to make it active.
March 14, 1986 6:54:46 am PST
Finch
Finch, NamesGV, ... should use approach of VoiceDB to re-import stuff.  Maybe a package to manage permanent connections?  Option to poll.  Built on that will be local/remote LoganBerry, and on that VoiceDB et al.  Will be nice entree to conversion to LoganBerry. (NamesGV is all right.  Uses hints plus the new optimized import approach.)
November 27, 1985 2:43:50 pm PST
Finch
In Finch, the initialization procedures are not protected by monitors or anything.  During rollback, more than one reason for starting/stopping Finch can cause trouble, which has been experienced at least once.
General internal-failure handling
March 14, 1986 6:53:46 am PST
Finch
Finch should catch WalnutDefs.Error and do something or other; happens when Walnut fails and can't read the message to see if we should read the database.  Probably assume there's a voice ID and go on.
Exception and error reporting, system logging, measurements, diagnostics
April 27, 1986 8:23:39 pm PDT
Finch
Reporting of problems in conversation log is still pretty bad.
Important
November 26, 1985 4:09:21 pm PST
Finch
Consider a way to get a busy test into Finch.
Some Day
April 30, 1986 11:42:07 am PDT
Why does the intelnet-converted number show up anyway?  Why doesn't that happen far enough downstream that nobody but the operating units see it?  Probably so that the conversions from 6xxx to 9496xxx and so on will work.
March 28, 1986 2:11:05 pm PST
Finch, Thrush, VoiceDB, and the ideas therein could be used in other domains.  Here are some examples of what I'm talking about:
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.







�Ê@˜™Icodeš
œH™HK™*K™6—J˜
head2š
œ˜
block˜M˜åM˜ÂM˜˜M˜Ö	—Mšœ±Ïy\œ‚
˜�M˜„—™M˜p—™6M˜‰—™3Mšœ!Ðboœ
Ðbxœª˜Ôšœžœ™<Mš
œ™šÏnœÏkœ
¡œ¡œ	¡œ
¡œ¡œ˜hJ™%Jš¡œ¡œ
¡œ¡œ
¡œ
¡œ˜7J˜
Jš¡œ˜J˜J˜—Jš
œv˜vJ˜±
—Mšœžœ�œÄ™öM˜™Mšœ žœé
˜ŽMšœ!žœÓ
™ù
Mšœ!žœ7˜]—™!MšœžœÊ
™í
—™HM˜ÖMšœžœµ
˜Ö
Mšœžœ?™bMšœ"žœÎ˜õ—™	Mšœ!žœ[˜�
M˜ïMšœ!žœ.™TMšœ!žœ.˜R—™Mš
ÏeÞ
˜Þ
M˜ÁMšœžœ¶
˜Õ
M™ü
š
œž
™ž
M™ç
M™ª
M™SM™ 
M™
—M˜›
M˜çMšœ!ÏsÏ
˜ð
Mšœ!£®
˜Ï
L™—˜L™—˜L™—M™˜L™—˜L™—˜L™—˜˜M˜—J˜——…—*Ä7’