Done
July 22, 1987 4:40:02 pm PDT
July 24, 1987 5:00:21 pm PDT
VoiceRopes
VoiceRopeImpl, on the client, can get the wrong serviceID -- one not corresponding to the recording service smarts and party serving the current connection. That would probably work out OK anyway, since all the services are identical, but VoiceRopeServer complains. Possibilities: improper implementation of serviceID registration in VoiceRopeServerImpl, improper manipulation of party and smartsID's in VoiceRopeImpl, overzealous caching of service information in VoiceRopeImpl. Initial examination yields reasonable behavior by all parties.
Solution: (a) One of the VoiceRopeServer procedures that is not conversation-dependent was called, causing the service interface to be imported. This also "reserved" a recording party. (b) Sortly thereafter, a Play was called, which returned immediately because info.imported was TRUE -- a bug, since the proper service-id wasn't yet known. (c) Subsequently, the timeouts for party reservation expired, and subsequent record/playback actions took place using the first party, whose corresponding service ID was correct in VoiceRopeImpl. Two users would get into a hellofamess. What's needed is a change to VoiceRopeImpl to keep track of looked-up service interfaces on a per-conversation basis. One more call, in most instances. Could cache service ID's per partyID, but doesn't appear worth it. Import can still be done just once, since it's OK (pragmatically) to know that all recording services implement the same code.
Fixed it up to work more or less like FinchSynthesizer, where most of the values are per-conversation.
July 19, 1987 9:08:02 pm PDT
July 24, 1987 5:02:39 pm PDT, something or other was done
VoiceRope
Routines should raise errors or return return codes when things go wrong. As of now, they complain but then return undesirable mainline values.
July 14, 1987 11:51:37 am PDT
July 24, 1987 5:03:47 pm PDT
Finch
Error, connection management
In general, FinchSmarts still assumes it's part of the user interface, wrt complaints and such. Not sure what to do about that.
There's evidence that conversation list maintenance isn't always done properly in the face of substitutions and deregistrations.
FinchSmarts should probably register own system state procedure to clean up conversation lists, etc., after connection goes away. Extract UnInitFinchSmarts code to this routine; probably good to do it both places.
January 28, 1986 6:18:12 pm PST
July 19, 1987 8:53:30 pm PDT
Should/must mark the position of playback/recording within a message in more or less real time. Takes a different approach to communications with services. This is presently simulated by assuming that playback is continuous and linear.
June 2, 1986 7:48:16 am PDT
July 19, 1987 8:52:14 pm PDT, was done some time ago.
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.
March 10, 1987 7:36:25 am PST
July 19, 1987 8:49:07 pm PDT
Finch
Should connect during installation.
June 9, 1987 9:52:56 am PDT
July 19, 1987 8:47:47 pm PDT, more or less under control
Thrush/Finch (Smarts)
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.
April 9, 1987 4:15:38 pm PDT
July 19, 1987 8:47:23 pm PDT, more or less under control
All
While developing full 7.0 system, lots of flakey connection stuff. Cranked up Thrush, VoiceRopeServer, Finch, TiogaVoice.
Tried to play a voice rope. Leaves connection in fully active state, attempt to play voicerope fails due to notInConv, connection stays open!
When a voice rope refers to a tune that doesn't exist, Bluejay ties up. When Bluejay ties up, BluejaySmarts doesn't recover at all well. In fact, it ends in a state where it half knows about a conversations it's in. Yuk.
New TiogaVoice Record and Play now share a Monitor Lock. Stephen's didn't. He has an entry procedure in the former call one in the latter. That has to get resolved. I don't think the current setup is right, so I won't fix it by splitting things up again.
May 29, 1987 1:25:46 pm PDT
July 19, 1987 8:46:41 pm PDT, hack fix that seemed to eliminate the problem.
Bluejay/Lark/???
The voice packet receive code in Bluejay craps out sometimes on playback when the Lark is also sending packets to Bluejay (due to a buzzy microphone, for instance); esp. if the first packet to arrive in that direction is a completely full voice packet or something. The effect is a bounds fault due to a calculation that tries to get a silence interval, in milliseconds, as a CARDINAL, from a silence value in a Lark packet that is apparently 177772B. The code deals in word indices rather than using a record type, so it's hard to debug and we (I) gave up.
July 14, 1987 11:51:37 am PDT
July 19, 1987 8:43:37 pm PDT
Finch
Error, connection management
Need here to document all of the activities that led to the creation of ThPartyClientImpl, and massive revisions to FinchSmartsImpl. Decided to contain the error management for ThParty calls in Finch to a single module, exporting a protected version of ThParty. A call-failure results in an attempt to reconnect to Thrush and then to reregister Finch. Only failure of that causes operation to fail (returns an additional nb code, usually.) Even at that, the next operation attempt will again try to connect. Also, the full Poll-response behavior has been implemented, so that if either Finch or the server finds the other missing, (a) the server will delete Finch's party, and (b) Finch will try at intervals to reconnect. Only explicit action by the user (or checkpoint code) actually disables Finch. The "Drop out" menu item is gone, but there's still an "Unfinch" command.
Services are simpler; if they fail, they retry, having first invalidated their interfaces so that a ThParty call is necessary to restore them. From there on, recovery should be normal. Perhaps there aren't enough complaints, yet.
November 27, 1985 2:43:50 pm PST
July 19, 1987 8:05:13 pm PDT (mostly under control)
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.
November 26, 1985 4:09:21 pm PST
July 7, 1987 4:32:32 pm PDT (see July 15, 1986 7:14:11 pm PDT, June 18, 1987 6:53:12 pm PDT)
Finch
Finch checks in once in a while, re-registers if gone.
March 28, 1986 2:16:59 pm PST
July 16, 1987 9:56:45 am PDT (fully replaced)
Finch
Improper partitioning of packages and interfaces in Finch
Ken pier found this bug:
Finch code guaranteed to fail
FinchToolImpl.CheckActive:
PUBLIC
PROC[handle: FinchTool.Handle]
RETURNS[active:
BOOL←
FALSE] =
TRUSTED {
If not active, try to make it active.
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.
March 14, 1986 6:54:46 am PST
July 7, 1987 4:31:03 pm PDT (superceded by June 1, 1987 9:05:16 am PDT)
Finch
Connection management
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.)
July 15, 1986 7:14:11 pm PDT
July 7, 1987 4:31:35 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
July 7, 1987 4:31:44 pm PDT (superceded by February 17, 1986 6:08:55 pm PST)
Finch
Substitution, mid-course registration and unregistration problems
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.
May 4, 1986 11:49:14 pm PDT
July 19, 1987 8:04:13 pm PDT, (error reporting mostly under control, will fix case-by-case)
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
July 19, 1987 8:04:32 pm PDT (mostly under control)
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.
June 11, 1986 6:19:11 pm PDT
July 19, 1987 8:03:57 pm PDT, (mostly under control)
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.
December 22, 1986 2:11:42 pm PST
June 22, 1986 9:07:53 pm PDT
July 19, 1987 8:03:25 pm PDT (not fully settled, but under control)
Finch
General error reporting and conversaion management
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.
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.
February 17, 1986 6:08:55 pm PST
July 19, 1987 8:02:43 pm PDT (obsolete)
Finch
Substitution, mid-course registration and unregistration problems
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.
Finch now gets a ThSmarts.CheckIn[$welcome] just after registration, a CheckIn[$goodbye] as the last report ever issued (I think), and a CheckIn[$hello] on occasion. In addition, it gets a Substitute[old, new] for each active conversation just after registration, and another when it gets removed from conversations, either because another Finch started and took the Poaching link away, or when the user manually disconnects Finch from the server.
Finch doesn't do the right thing about any of these reports, yet. It even gets an error complain about no such party when trying to respond to the disconnect Substitute call. I (DCS) plan to work on responding properly to CheckIn reports, and only later to see if the Substitution stuff needs to be dealt with further.
June 1, 1987 9:05:16 am PDT
July 19, 1987 8:00:22 pm PDT
Thrush/VoiceUtils/All
RPC failures not uniformly dealt with for secondary interfaces, such as multicast. What is the story with service interfaces in that regard? Need to check all of them, do something useful. Use Finch upgrade as a model?
Possibly there's a problem with the attempt to reestablish NameDB connections when the server crashes and comes back up. In one such instance, the client machine was looping, using a lot of CPU and allocation resources. Also, Check handling of NameDB connect failures. Currently, ERROR in NameDBImpl reaches debugger!
Multicast doesn't matter if the standard variety doesn't use RPC.
N -- one-time import and immediate use, by Larks; OK
l -- standard use is local binding; OK for now
O -- well-tested, self-protecting interface; OK
R -- is usually used in local mode. During testing, can be reestablished by re-issuing the
Import command; OK for now
x -- don't know yet
s -- service interface, with local binding only; OK at present
o -- tested, self-protecting interface; known to have problems, must be checked
S -- service interface, with remote binding; must be checked
T -- thrush interface; must be checked
% ls -f -b &v/*RpcControl.bcd!h
N AgentRpcControl.bcd!24
O LoganBerryRpcControl.bcd!1
O LarkOpsRpcControl.bcd!8
O LarkSmartsRpcControl.bcd!53
l BluejayUtilsRpcControl.bcd!2
l LarkRemoteControlRpcControl.bcd!4
R MulticastRpcControl.bcd!10
O NameDBRpcControl.bcd!xx
O ThSmartsRpcControl.bcd!16
T ThPartyRpcControl.bcd!39 (OK for Lark, Bluejay; still needs Finch work)
S LarkFeepRpcControl.bcd!5
S LarkTTYRpcControl.bcd!2
S SynthesizerServerRpcControl.bcd!6
S VoiceRopeServerRpcControl.bcd!5
%
June 18, 1987 6:53:12 pm PDT
July 7, 1987 4:19:27 pm PDT
Thrush/Finch
Evidence is that Finch doesn't properly record what's happening when splicing in. Should get a Substitution report. Maybe report is issued before Finch is fully aware? Check it out.
Specific questions and notes:
1. Does a Substitute happen just as the Finch is deregistered, assuming the connection still works (voluntary drop-out)? If so, it's not causing the active-conv line to be deselected. Finch does not receive a Substitute at that point. Perhaps only the still-remaining parties do. If so, change it. Wasn't reporting to the old party. Now it does, when the old one is an $individual. Finch doesn't then respond properly, though.
2. Does a Substitute happen first-thing when a Finch reregisters? If so, it's not properly re-displaying the state of things. That part appears to be working now.
3. "Other telephone failed" is an improper error message; should be either "Etherphone failed" or "Manager failed", depending. Changed it to "Etherphone failed". When it's the Finch that fails, perhaps no one will notice the message.
4. Finch with no lark receives an incoming call because it's from an Etherphone; Finch poaches on calling Etherphone's back door. If Finch then drops out, there are two problems:
a) Conversation is zapped, even though it needn't be.
b) It's zapped in such a way that caller's back door party is still engaged, even
though its corresponding conversation is gone. Furthermore, the back door
smarts still thinks it's active in the conv. Find this specific problem, but
also refuse to honor partyEngaged field as a problem if one isn't still in the conv. This was a Substitution screwup; fixed it, left the rest alone for now.
General comments about registration, deletion, and such:
As parties join a conversation, they increase conv.numParties. Normally, no party actually leaves the conversation until they're all idle; then they all do. So conv.numParties is never reduced; numIdle just increments to catch up with it. This allows some forms of monitoring after leaving the conversation.
But when a party is deleted, and doesn't have a party to take its place (e.g., a poachee), it is removed from the conversation (triples deleted), since otherwise it would be hard to find a time to do it. In that instance, the number of convStates is less that conv.numParties. If anyone, Finch in particular, is counting on getting a PartyInfo with that number of parties in it, it will sometimes be disappointed. Does that matter?
July 6, 1987 12:05:51 pm PDT
July 6, 1987 12:14:18 pm PDT
All
Need to record here the ThSmarts.CheckIn design and implementation. In summary:
ThParty polls smarts at intervals, using CheckIn call. calls include birth/death/just-checking information, and a very conservative estimate of when the next poll will be. Smarts may choose to become concerned when more time than that passes, using ThParty.CheckIn to be certain the party is still there (a missing poll is not firm evidence of a dead server).
Birth event happens just after the party has been enabled. Death event happens after all other reports to that party have been made -- shoudn't expect any more until reregistration -- won't happen, of course, if the deregistration happened because of communication failure with the smarts. Just-checking events happen while the party is thought to be alive and well.
June 21, 1987 11:39:12 pm PDT
July 6, 1987 11:41:38 am PDT
Thrush
Checkin shouldn't be called directly from poller; but on the other hand, if queued, might mess up the numReportsOutstanding counts??? No, Maybe it can go around them. Also, should disable polling stuff in Lark if it stops happening in the Smarts? Hard to do, but otherwise, will get zillions of poll operations after they stop. Gluck.
June 21, 1987 10:30:03 pm PDT
July 6, 1987 11:39:34 am PDT
Thrush
See when party.enabled is reset during Deregister. What would it hurt if it were done early? It's not done at all. Party is definitely going away, by the time Deregister is called.
January 13, 1987 11:50:58 am PST
June 18, 1987 6:54:02 pm PDT
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.
7. Look into who should do what based on voicePath information when a Lark fails and leaves a Finch stranded. In particular, leaves the call unable to continue, for front door calls, but not back (could pretend it was, tho). Finch can do something intelligent in Substitute, or ThParty can do something standard during the substitution activities. What? Lark's party is idled, so this doesn't happen.
March 9, 1987 3:25:26 pm PST
June 17, 1987 1:00:21 pm PDT
Thrush
Beep on hangup is a frequent, annoying occurrence. It represents an avoidable race, I'm sure. Scan old notes for what causes it. This is due to switch state being set in LarkInImpl synchronous with reporting of Lark events, but actions being taken on switch states later on in queued handling routines in LarkSmarts. Not sure why it's done this way; possibly due to LarkInImpl report-time dependencies. Requires additional study to decide what to do. Usually will not be much of a problem when the server and the Larks are on the same net. Consider queueing a LarkIn routine that updates the state and then invokes the next-level procedure.
June 12, 1987 4:23:34 pm PDT
June 16, 1987 5:42:23 pm PDT
Thrush/Finch
Bell, Strowger, and Swinehart registered, Swinehart poaching on Bell. Then Strowger visits Swinehart.
Using Swinehart's back door, call Strowger.
Both Strowger's phone and Bell's phone rings.
If Bell's phone is answered, Strowger's phone shuts up and all is well.
Swinehart's profile says "multiring: 50".
If Strowger's phone is answered, Bell's continues to ring for 50 seconds. After 50 seconds, all is well.
If somebody answers it, it seems to try to be connected to something,
and Strowger's speaker light blinks.
I think it was supposed to drop out, due to bilateralness, right away.
If Swinehart's profile says "multiring: false" instead, all is well.
If Strowger's profile says "multiring: 50", and Bell's phone is answered, Strowger's shuts up,
but (I believe) only because it has now to be a forwarder to Bell; after the 50 seconds,
another action takes place attempting to disconnect Strowger or something.
But the conversations in all cases remain well-behaved and synchronized, so we're close.
Problem was that the bilateral-conversation tests and the provision of ConversationInfo that made the
tests possible were not good enough. Now they seem to be.
June 12, 1987 11:46:22 am PDT
June 12, 1987 2:55:53 pm PDT
Thrush/Finch
Poacher with a home lark but no local Lark placing a call tied things up in knots: Finch went $initiating and never came out, home trunk placed the call and went $active and never came out. Fixes, in order of importance:
1. Add voicePath bit to PartyInfo, so Finch can determine whether there's a voice path.
2. Verify that Finch's implementation of Substitute causes reexamination of voice path stuff.
3. Finch doesn't initiate a call if there's no voice path => $failed.
4. LarkSmarts should go $idle when it finds itself in $failed state and can't get at the hardware (caused by Finch).
5. Trunk should time out and go $idle[$error]:
a) $initiating, after a time.
b) $active and no other party $active, after a time. (what about held calls????)
6. Finch should time out $initiating => $failed, after a time, if not otherwise taking care of it.
June 10, 1987 8:59:35 am PDT
June 12, 1987 11:46:12 am PDT
All
Finch with no Lark ties things into horrible knots when user is callee and has a running Etherphone but not where Finch is running. Try calling that user from another Etherphone! It's not much better when calling on the back door. Problem: poaching set up wrong. Solution (courtesy PTZ):
Poaching[individual, caller]:
workstationOwner ← $workstation-1[machine[individual]], as an atom.
poachee ← $telephone[workstationOwner], if it exists (standard Lark-exists poaching case)
else poachee ← select caller.type from
$tel = $trunk[$telephone
-1[caller]], with phone# = officeNumber[workstationOwner (
!!)]
This solves the problem of calling from another Etherphone.
$trunk = $telephone[$trunk
-1[caller]]
This sort of solves the problem of a totally outside call; Finch lights up in the poaching office, and the poacher's home phone rings as usual!!
Note that this will stop working in all instance when remote terminals get into the act.
June 8, 1987 9:45:47 am PDT
June 9, 1987 5:40:44 pm PDT
Thrush
Remaining problems with the fd/bd crowbar.
Or does it? Once, with Finch involved too, somebody decided to go ringing, leading to
a blow-up where there wasn't a convEvent and one was expected. Make sure there
always is one except when CreateConversation fails? Naww. Just don't try to use it if it
ain't there. Repair this in Advance in LarkSmartsSupImpl.
BD call when FD in use, no poaching complications, encounters crowbar instead of
simply busy rejection.
Possibly can wait to crowbar until the advance to ringing is attempted? Need to repeat this
whole sequence and try again.
LarkTrunkSmartsImpl.pd includes a variable that determines whether CreateConversation
needs to check FD/BD conflicts. It is set FALSE. This causes an anomaly when the
poacher's home phone is off hook and an outside call comes in, but otherwise seems about
right. Finch can do some things to reduce the impact of the anomaly, but need not to
maintain system consistency.
June 8, 1987 3:52:49 pm PDT
June 9, 1987 11:50:11 am PDT
Thrush
Shouldn't go into $failed state if on hook and not originator; $idle instead. Had a situation where a caller got into trouble, terminated in $failed state, callee went from ringing to fast-busy. Annoying to neighbors.
Also, shouldn't go into $failed state if that would cause hardware conflict. In such a case, choose $idle! (already done!)
January 26, 1987 11:39:13 am PST
June 9, 1987 3:23:25 pm PDT
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.
June 9, 1987 9:50:35 am PDT
June 9, 1987 9:55:04 am PDT
Finch
Include FinchSmartsImpl in Finch exports. Maybe it's already done.
June 8, 1987 4:57:23 pm PDT
June 9, 1987 9:47:11 am PDT
Thrush
Timeout for initiating should be longer, to give the pending timeout time to do its thing. When it does time out, it should put calling terminal into error state (fast busy), not normal termination state.
December 22, 1986 2:31:45 pm PST
June 8, 1987 9:39:52 am PDT
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.
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 14, 1987 11:22:48 am PST
June 8, 1987 9:41:10 am PDT (need to check Finch behavior, but most of this has been dealt with)
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.
August 12, 1986 9:10:27 pm PDT
June 8, 1987 9:42:33 am PDT
Thrush
Need to arrange for the $deferanswer database entry to apply to call rejection -- don't reject for a while either; need a way to requeue that, too. And a way to combine the code for setting the database to default value.
February 12, 1987 7:48:39 am PST
June 8, 1987 9:42:47 am PDT
All
Consider the LoganBerry conversion for NamesGV (all of it???????)
February 10, 1987 6:04:04 pm PST
June 8, 1987 9:43:09 am PDT
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.
April 20, 1987 5:42:45 pm PDT
May 1, 1987 2:27:50 pm PDT Accept phenomenon as a good thing.
NameDBImpl
Timestamps on cache checks extend the log too fast. Need an in-core cache of names and timestamps, or need to notice that it's OK to make checks more frequently, in order to reduce the load. Alternatively, think of it as a log of user activity, compress it once in a while, and be glad it's there.
April 17, 1987 11:56:35 am PDT
April 20, 1987 2:03:44 pm PDT
Finch
Making Intelnet calls did not work, from the workstation or from the telset. I got several clicks, then a dial tone. I ended up dialling it from the back door. Making local calls did work, however. (Polle)
I can't reproduce this problem. (Dan)
April 17, 1987 11:54:50 am PDT
April 20, 1987 2:57:36 pm PDT
Finch/Thrush
Tune-changing hack for visiting is wrong. Do something else. The wrong approach: on a timed basis, change the ring tune for the owner of the called phone to be the same as the callee's tune. Right: when deciding what ring tune to use, use the intended callee field. (Polle)
As of now, seems to be doing things right, using intended stuff. (Dan)
December 29, 1986 11:34:39 am PST
May 1, 1987 2:28:49 pm PDT
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. Works OK as of last test; possibly was being tested wrong.
April 6, 1987 7:57:46 am PDT
April 7, 1987 5:06:47 pm 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).
So far have only succeeded in initializing the choice of database location and repeating the existing LoganBerry stuff, and selecting attribute fields.
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.
February 26, 1987 7:47:02 pm PST
ThParty, Thrush
Changes to Visit stuff.
Visit visitorname {password}
if visitorname#self, registers visitorname as visiting logged-in-name, ie issued at visiting location.
=> calls ring at both locations
Both Finches see the call (except for some anomalous back door cases)
if visitorname=self, must be at home location
means cancel visiting
Password need be provided only if visitor's database demands it. Since calls ring both places, malicious calls to visit won't prevent ringing unwitting visitor's home phone.
Unvisit {visitorname}
issued in one of two places:
1. at visitor's home, in which case visitorname is optional. In this case no password is required, because the command can use the UserCredentials version if necessary.
2. at a previously visited location. This time any required password must have been remembered by the visitee's code.
A person should only "Unvisit visitor" if he believes the visitor is still visiting a person. With the change to Unvisit, though, a mistake in this area isn't serious.
needed from ThParty:
1.
Visit:
PUBLIC
ENTRY
PROC[shh:
SHHH←none, visitedParty: PartyID, visitingParty: PartyID, visitingPassword: GVBasics.Password]
RETURNS [nb: Thrush.
NB←$success]
UserProfile default is $visitpasswordrequired: FALSE. Finch can demand password either when user explicitly reqests ("Visit -a visitor", a for authenticate) or when an attempt to Visit without supplying one fails.
2.
Unvisit:
PUBLIC ENTRY PROC[shh:
SHHH←none,
visitedParty: PartyID, visitingParty: PartyID, visitingPassword: GVBasics.Password]
Password not presently required or heeded.
RETURNS [nb: Thrush.
NB←$success]
Only Unvisit somewhere visitingParty is visiting. If a password is required here and the visitee does the calling, password should have been remembered by visitee. On a restart after a crash, visitee might not have enough information to cancel password-enabled visiting.
3.
DescribeParty:
extended to return information about poachers or poachees, visitors and visitees.
DescribeParty, not GetPartyInfo, is where you can find out about Poachers, Poachees, Visitors, and Visitees. GetPartyInfo doesn't work unless there's a conversation cooking.
Unvisit is now willing to return some error nb codes as well as $success. All are ignorable, though, because all are variants on "what you asked me to do was either incomplete or nonsensical, so I didn't do it." See ThPartyInitImpl.Unvisit.
The default in absence of a database entry is $false -- no password required.
February 17, 1987 6:04:15 pm PST
February 23, 1987 6:57:02 am PST
VoiceUtils
There's an extras interface in there somewhere.
February 17, 1987 4:57:19 pm PST
February 17, 1987 6:00:53 pm PST
Thrush
ThParty.Visit adds visitingPassword: GVBasics.Password to parameter list; also ThParty.Unvisit. Both may now return $passwordNotValid as additional NB code. If password is all 0's, it's a request to see if the database for the visitor contains $visitpasswordrequired: FALSE.
February 10, 1987 6:10:16 pm PST
February 17, 1987 6:03:46 pm PST
Thrush
ThParty.Visit should accept encryption key; database determines whether it's required.
January 28, 1987 8:07:35 am PST
February 17, 1987 6:05:21 pm PST
Thrush
Be sure that ChangeState error handling eventually arranges a ForgetConversation for all errors that won't/haven't caused the Lark to fail anyway.
February 9, 1987 8:05:28 am PST
February 10, 1987 8:36:54 am PST
VoiceUtils
Add a command to enable standard mail-reporting. Clean up the timeout stuff to use only the MBQueue process (watch your entry procedures!) Rethink the #intervals stuff. It's probably a krock.
February 6, 1987 9:53:28 am PST
February 8, 1987 7:47:52 am PST
Thrush
Add an event report to the completion of switchhook flashing. Then people can program forwarding applications and such. Not reliably, but -bly, anyhow. Doesn't report if actionID in request is 0. Doesn't work well if multiple flash requests are enqueued.
February 8, 1987 8:50:49 am PST
February 8, 1987 11:12:14 am PST, needs testing yet
VoiceUtils
Better error reporting:
Inhibit local logging of problems and reports when the number exceeds some threshholds (greater for reports than problems). This doesn't apply to the problem report that indicates the threshhold has been exceeded.
Include a priority level as a parameter to the Problem functions, default = highest.
Indicate for each priority level whether problems at that level should be reported by mail, and if so to whom (via Simple Mailer).
Implement all the above policies.
January 24, 1987 5:09:13 pm PST
February 8, 1987 8:50:47 am PST, see February 8, 1987 8:50:49 am PST
Thrush
Consider sending Grapevine mail when really bad things happen. Possibly in place of just ERROR! Also maybe in one class of Problem, which is truly not expected to occur. This all has to be buried deeply enough that clients don't have trouble using it.
January 24, 1987 5:09:13 pm PST
February 8, 1987 8:50:54 am PST, see February 8, 1987 8:50:57 am PST
Thrush
Should we crowbar logging when there's too much of it? Otherwise, we get the full-disk syndrome. See also previous suggestion about Grapevine logging. Must definitely prevent that from going into Wallpaper mode!
February 5, 1987 0:08:28 am PST
February 5, 1987 0:11:04 am PST
Thrush
As part of forwarded flash stuff, did the following:
1. Add interfaceID field to Thrush.InterfaceSpec. It's to be bound to a RefID.Seal[localInterfaceRecord] for a local version of the service. Optional.
2. Importer, having looked up InterfaceSpec, can try to Unseal and NARROW the interface record; can even choose not to try to bind to the RPC version when the former fails. To be surer, can check own host ID against interfaceSpec.hostHint.
3. Tried it out with remote Flash. Worked nicely, but the flash reversion didn't.
February 4, 1987 11:54:11 pm PST
February 6, 1987 9:48:26 am PST
Thrush
Forwarded flashing doesn't quite work. During the flash, the remote connection is apparently disassembled, or maybe half of it. After the flash, it isn't set up again properly. When the call is terminated, the phone with the BD on it is in some strange bad state and dies soon after. Wasn't doing switching right -- was probably shutting down the Ethernet connection.
February 4, 1987 6:33:21 pm PST
February 4, 1987 11:53:56 pm PST
Thrush
Trunk-flashing needs to work for forwarded calls:
1. Rename the Feep interface? (didn't do it.)
2. Add code to do it to the Feep interface and implementation.
3. Import Feep interface to LarkSmarts, based on how Finch does it, when flashing is called for. Be careful about RPC vs. local, but it's time to deal with that anyhow.
4. Think about any other Trunk-specific stuff to do.
February 4, 1987 6:33:21 pm PST
Thrush
Feeping should work right for forwarded calls:
1. Make sure an attempt to Feep when there's no feepee behaves more or less right.
2. Arrange for non-noisy feeping when the call is forwarded.
May 1, 1986 9:51:43 am PDT
February 4, 1987 6:33:21 pm PST, superceded by two items dated this time
Thrush
Find out how hard it is to get trunk-flashing to work on forwarded calls! In fact, test trunk-flashing at all. Works when not forwarded, doesn't work in any way shape or form when forwarded. Wonder why. Feeping does funny things, too.
February 2, 1987 1:39:15 pm PST
February 4, 1987 8:46:42 am PST
Thrush
**0 to reach back door dial tone, when forwarded, somehow switches in the speaker on the forwarding Lark. So does feeping (either the speaker or the handset, forget which). That's weird, because if there's a number it doesn't happen. Except that the last time I tried, it didn't set up the through voice path at all. Other things broke then, so I couldn't pursue it. In general, outgoing forwarded calls don't set up right. Wonder whether it's the Trunk or the Lark Smarts that's broke. Quite likely the Lark. Suppose the connection doesn't get made. Outgoing forwarded calls go through state transitions that (1) cause the Lark connected to the back door line to briefly set up a local speakerphone call, switchingwise -- at least if signalling gets done in time to allow it, and (2) do an EnterLarkState from active to active, trans=ksp, and that isn't one of the states that support setting up connection specs. Has to be changed to be, I guess. Problem was (1) ksp, and (2) forwardedCall wasn't computed early enough.
December 2, 1985 12:37:30 pm PST
February 2, 1987 4:02:35 pm PST, obsolete
Consider a setting, like attended, that puts off the destruction of old conversations. Perhaps in a loop until the setting is turned off. Good for anything?
February 2, 1987 3:38:19 pm PST
February 3, 1987 7:55:02 am PST
Thrush
Have broken narcissism stuff, again. If A poaches on B, and then uses B's phone to dial A's number, A's home phone should ring. Get busy instead, now. Not only that, if B's phone is used to dial B, things just don't work -- silence, then phone rings when you hang it up. Determine why. All due to (1) bad testing in ThParty.AlertOne, and (2) having eliminated the code that went for $telephone if $individual were narcissistic.
December 18, 1985 11:52:01 am PST
February 2, 1987 4:00:12 pm PST, obsolete
Thrush
During connect attempt, if get "initiating" in but "notified" fails, should enter error state or something — all smarts. Unlikely event, though.
December 2, 1985 2:12:13 pm PST
February 2, 1987 3:59:34 pm PST, obsolete
All
Holes in the present implementation:
Conferencing is not supported at high levels.
AssessDamage isn't implemented.
Bluejay completely unimplemented.
Finch hasn't been modified to match.
Prose, Intervals aren't anywhere.
$Visiting not implemented.
February 2, 1987 1:46:37 pm PST
February 2, 1987 2:01:45 pm PST
Thrush
If substitution is done at a time when an old conversation is dying, reports can later be issued that refer to non-existent conversations. Must make the right NIL-checks here and there. Will do it where we can find problems, but will possibly have to revive this issue again.
June 29, 1986 11:22:50 am PDT
February 2, 1987 3:04:37 pm PST
Thrush
Finch death during a forwarded BD call causes partitioning or something: hanging up the FD doesn't cause the Lark with the BD to hang up. Check Poaching/substitution algorithms. Consider putting all parties into the conversation. Apparently mostly under control, anyhow. Possibly after terminating conversation, can't do BD-forwarded calls any more?
June 11, 1986 1:13:10 pm PDT
January 24, 1987 4:51:49 pm PST
All
Need to collect up the various values of nb, service reports, and so on, to make a UserProfile-like catalog. Not easy, due to indirections.
May 1, 1986 1:12:11 pm PDT
January 24, 1987 4:51:51 pm PST
Intervoice
Document nb=$voiceTerminalBusy case, change of $noTrunkParty to $noRelatedParty.
January 24, 1987 5:06:31 pm PST
Thrush
ThSmartsPrivate.Getconv[...., non-null, TRUE] => complains if we don't know about this conversation. Or have a parameter? That way, callers don't have to complain.
January 24, 1987 4:44:55 pm PST
January 29, 1987 2:27:24 pm PST
Thrush
LarkSmartsSupImpl.ChangeState: must handle all errors; nb is returned as an advisory for further action by some of the routines that call it. If that number turns out to be none, pull the nb return. Caller of ChangeState need do nothing to deal with fatal or call-ending errors that result from the call. ChangeState must also not leave call in unstable state (e.g., $initiating or $pending). Those states result from very special code, and any kind of failure cannot be allowed to leave them there.
November 26, 1985 4:09:21 pm PST
January 29, 1987 2:29:18 pm PST
Thrush
Need to put Reports/Problems in the point of detection of each problem, and other strategic places. Some for normal flow, some for exceptions. Need to parameterize each appropriately; many now have just constant messages.
January 13, 1987 11:50:40 am PST
January 17, 1987 4:44:23 pm PST
Thrush
For the gazillionth time, I've broken narcissism. No reports, no response, no nothing! Error handling in Finch isn't so great, but it's a little greater now. BY was broken again, too.
January 13, 1987 11:56:30 am PST
January 19, 1987 5:40:05 pm PST
Thrush
A visits B, B has a Finch but no Lark, and C calls A on the front Door. At present, the forwarding LED flashes, A's phone uses its back door to call B! That's just a bug. In fact, what happens is that the visitee doesn't get found through GetParty, thus it doesn't enjoy a fresh SetPoaching before the call is placed, so previous poaching setups still prevail. In this sort of case, that's likely to be wrong! Must arrange to do the SetPoaching in this case. Check out what happens when own party is located, too! That's OK. Now there's a SetPoaching in AlertOne. Probably the one in GetParty could go away, but it's not particularly expensive.
April 27, 1986 6:39:20 pm PDT
January 19, 1987 5:40:42 pm PST, superseded or not worth pursuing.
Thrush
When RPC failures occur and are manually aborted, party notification queue trying to end pending converations are left unfulfilled or something, and (harmless) idle conversations stay around. Probably only happens when attended allows aborting, and should proceed from attended problems anyhow. Yuk. By setting attended, appears there are a lot more failures on same machine than I once suspected.
February 16, 1986 3:25:59 pm PST
January 19, 1987 5:41:10 pm PST, superseded by Doug's Local/remote Loganberry stuff.
VoiceRopes
WalnutVoice command should accept spec of no server; WalnutVoice implementation throughout should be willing to assume that LoganBerry is local, and not import it. Better yet, determine thorugh inspection that LoganBerry is local?
December 23, 1986 3:49:23 pm PST
January 17, 1987 5:40:48 pm PST, obsolete, see later entries.
Thrush
What if visitee has no FD? Do things still work?
December 22, 1986 2:33:58 pm PST
January 19, 1987 5:43:10 pm PST, superseded by simpler January 19, 1987 5:43:15 pm PST
Thrush
The current design says that almost anything will cancel visiting, including call-initiation from visitor home site, or deaths of anybody at all. It's not clear what the current implementation does. Cancellation of visiting doesn't a priori cancel any calls. Do we really want to cancel when calls originate from visitor home site? Somebody else might be using that phone. Leave it alone until manually cancelled, for now. Time out visiting once it's done in the database. Need a way to manually cancel from visited site or from visitor's home base! Check minor Finch simple stuff. Truth: this needs to be redesigned.
April 24, 1986 3:17:04 pm PST
January 19, 1987 5:41:55 pm PST, declare victory until evidence to the contrary
Thrush
Now worried about what happens to splicing when poachers preempt each other. Possibly works correctly by composition -- that's what you'd like anyway. Wait and see. {Seems to work in simple cases.} Also worried about what happens if poacher is already active somewhere else, or something? Now active twice? Can that happen?
January 17, 1987 2:55:54 pm PST
January 17, 1987 3:41:50 pm PST not completed
RPC
Made a version that carried whether decryption had been done along with the packet, by changing the packet's type.subType from 3 to 7. There is under some circumstances I couldn't reproduce a bug with it, in that it sometimes resends such thing without resetting it to 3. I built a VoiceUtils, Thrush, and Finch using this new one, but then I canned them. I'll keep the version (Cedar 6.1, but that's easy) around for a while, in case some problems arise with multiple-decryption. Else it's not worth inflicting some new kind of bug on the world.
January 17, 1987 2:52:28 pm PST
January 17, 1987 3:41:28 pm PST
Thrush
I've broken speakerphone switch clicking! Always treated as on, then off. False alarm, I guess, not reproducible.
January 16, 1987 3:00:33 pm PST
January 17, 1987 3:42:06 pm PST assume Thrush is OK, until proven otherwise.
Thrush
Not all Thrush RPC interfaces are protected against server rebirths -- Multicast stuff, for instance. Probably this isn't a problem in the production system. Worry about all Finch/Thrush interfaces, though.
January 11, 1987 2:57:09 pm PST
January 11, 1987 4:26:50 pm PST
Thrush
Lark buffer connections must be disconnected before changing them. Temporarily, set up to fully disconnect before connecting, always. That seems to be working well enough to avoid doing the other thing.
November 24, 1986 9:18:39 pm PST
January 16, 1987 2:50:07 pm PST
RPC
Discuss RPC changes with some Guru. Decide how to make a regular part of the system.
January 11, 1987 2:19:33 pm PST
January 11, 1987 2:50:06 pm PST
Thrush
Problems remaining with conferences involving trunks and the like.
Consider A visiting B, then a trunk call to A. If B answers, A's telset responds by going idle, in the standard case. The standard response is to put A's Lark idle, but its trunk is still in use. This case isn't detected, and the line is dropped. Once forwarding is in place, $telset doesn't control the hardware. So just avoid any transition from LarkSmarts in this situation. I think that works out OK.
December 22, 1986 2:34:30 pm PST
January 11, 1987 2:22:36 pm PST obsolete
Thrush
Concern about conferences and trunks. Should find low-level smarts-level way to avoid trying to conference a back door with anything.
July 1, 1986 7:41:42 am PDT←
January 11, 1987 2:23:08 pm PST obsolete
Thrush
Putting poacher and poachee into conversation made easier by sharing state among them? Still have the increased incidence of $stateMismatch to worry about, which is only need for loops.
January 11, 1987 2:14:58 pm PST
January 11, 1987 2:19:27 pm PST
Thrush
Restrictions on conferencing when trunks are involved.
At ThParty level, add to Advance (intended for advance-to-active) a parameter requesting a "bilateral" conversation, which means at most two parties can be active. If the request is made when 2 or more are already active, the Advance fails, whereas after the bilateral conversation is established, further attempts to increase the number of parties fail.
Now that things are more general, a lot of the code that deals with setting up connections doesn't work. Fixing this required changes to ThParty.GetPartyInfo so that the Smartses can be smarter, then much smarter Smartses (lark and trunk). They know about bilateralness and use it to do different kinds of switching. LarkOutImpl's control over buffer-assignments in the Lark also has to be more incremental, to avoid unnecessary interruptions in service when things are changing trivially. Finch needs to be evaluated still to get everything reported right.
January 11, 1987 2:11:41 pm PST
January 11, 1987 2:14:50 pm PST
Thrush
FD/BD crowbar
The only place to do this reliably, without races, is at the Party level. Added Other relation between $trunk and $telephone party, set up in a type-specific way by Register, changes to GetParty (type-specific), CreateConversation (optional, option exercized only by Trunk Smarts), and Alert (mandatory) that refuses to do the requested thing in a conflict situation, best-defined by statements in the code. GetParty addition allows attempts to get a trunk to fail quickly, so that alternate trunks can be tried; but when it's not a trunk, allows things to procede further so that they can be recorded.
Accept some lossage of information at Finch level by this choice -- sometimes not everybody learns fo the attempted usage.
December 29, 1986 4:38:13 pm PST
January 11, 1987 2:11:29 pm PST obsolete
Thrush
See next two items -- FD/BD crowbar.
Front door stuff:
LarkSmartsSupImpl:
$silence, $idle, $busyTone, $errorTone, $dialTone, $ringBack, $ringing, $talking from SetLarkState, lark only
Back door stuff:
LarkOutImpl:
$trunkSignalling, in QueueFeeps
$trunkTalking, in TonesDone
LarkSmartsImpl:
$trunkFlashing, in CmdBackDoor. Check this out carefully. From $trunkTalking only, though.
LarkTrunkSmartsImpl:
$trunkTalking, $trunkSignalling, $idle
$trunkSignalling, via QueueFeeps, in Feep
LarkInImpl:
$trunkTalking, via TonesDone, in RecordEvent. From $trunkSignalling only, I wager.
Both:
LarkSmartsSupImpl:
. . ., $idle, . . .
LarkTrunkSmartsImpl:
. . ., $idle
LarkSmartsInitImpl:
$idle, in EnableSmarts
Conclusions:
Front and back door transitions are quite independent of each other, incredibly enough. $idle is the only point of crossing. The one in EnableSmarts is OK. Will now check the others. Looks like either side could choose to send the state $idle using the same code, so that it's impossible to tell which is meant. Should add a $trunkIdle state request that gets turned into $idle after the trans-legitimacy test in LarkOutImpl. $idle is ignored if the current Lark state is a trunk-related one, and vice versa? Has the danger of never hanging up if these things get crossed. Also worry about what happens when the other end of a forwarded call
December 17, 1986 11:50:54 am PST
January 11, 1987 2:10:30 pm PST obsolete
Thrush
Work harder sometime to do all state-change rejection based on mutual exclusion (lark/trunk) at this level. Talking about front door/back door limitations. LarkOut level should catch and reject attempts to over use the hardware. Possibly by generating synthesized input events to indicate that output events were not honored?
June 29, 1986 12:37:56 pm PDT
January 11, 1987 2:10:44 pm PST obsolete
Thrush
The $voiceTerminalBusy thing still isn't settled. BD incoming calls with FD offhook don't alert the connected Finch. Test s/b based on consistency check F[telsetState, larkSmartsState, larkTrunkSmartsState, larkState, ringDetState?] returns {ok, conflict, impossible}: conflict is a conflict between FD and BD, where one is already active; impossible is an error state that needs fixing. EnterLarkState calls it to be sure things are OK and fails if not. Others can call when change is imminent, to determine whether, for instance, to open a conversation, or to advance/cancel one. Maybe EnterLarkState could reduce the number of internal tests, then. Is this the same as April 24, 1986 3:17:04 pm PST?
December 23, 1986 11:16:22 am PST
December 27, 1986 5:45:34 pm PST
Thrush
Management of Extension triple doesn't work right, when the telephone number associated with a Lark or person or something changes. Oops. Current implementation ignores extension information in the GVNames database, looking instead in the current white pages! Not surprisingly, extensions didn't change when we changed the GV database. Hmph!
December 22, 1986 10:36:59 am PST
December 29, 1986 11:36:28 am PST
Thrush/Finch
GetParty[text-to-speech] isn't working right. Confusions about who is being called (self? last other callee?) That's not true. Can't get the synthesizer to work in the Thrush 7 world, though. Connection establishes, no noises, connection doesn't break. No events/reports? Works OK in released system. Didn't work because it wasn't plugged in. Must run LarkSynthesizerPackage, then issue LarkSynthesizer <instance>. However, see next message.
December 23, 1986 3:54:41 pm PST
December 23, 1986 4:01:37 pm PST
An explicit design decision was thought for a time to be a bug: if you poach on somebody else's phone, calls in progress at the time don't register on the new Finch, nor do incoming calls to the phone's owner register there. This is considered correct, if there's to be but one choice. Something of the SCL flavor (let the user look around a bit) might be a good thing to add here, though. Let's think about how much a user should be able to see of the state of the system.
December 23, 1986 11:17:34 am PST
December 23, 1986 11:57:23 am PST
Thrush
Strange progress reports when Strowger Visits DCS, Strowger is off Hook, Terry calls Strowger. Rejecting Lark continued to receive reports, more or less correctly. The complaint about strange progress reports has been removed.
December 23, 1986 11:17:34 am PST
December 23, 1986 12:15:47 pm PST abandoned.
Thrush
Setup as in previous case. Terry runs Finch, and voice path is cut off, but system still thinks the conversation exists. Was not repeatable.
August 7, 1986 5:19:44 pm PDT
December 22, 1986 2:35:30 pm PST
Thrush
Doing Visiting incrementally (major revision, which feels like it will work):
Add ThParty.Visit and ThParty.Unvisit.
Only $individuals can be visited.
Visitors can be $individuals or $telephones.
Visiting means that Alert will alert the visitor and the visitee, independently. Alert will include the intended party as well as the actual party, which will be available everywhere. Only reason this can't be done by visiting Finch is that visiting Finch might not exist; Lark has to do it. Possibly all visiting cancellations can be done from smartses, though.
Before notifying the visitee, Alert will copy visitor's ring tune, with short timeout, so that call rings in with caller's tune. Or maybe the visitee can do that, using the intended-party info (TBD how that is passed on to called party.) In line with smarts taking over more of the action.
It's simpler than that. SetupRingTunes in LarkSmartsSupImpl simply chooses the intended party's tune over the called party's tune. The right thing happens. Should also choose all the other intended party's attributes, except type.
Non-answering site should not go on ringing forever. Choices (choose some):
drop out immediately
drop out after a while, ringing all the way; answering possible until then.
remain in ringing state, but shut up, either for a while or for the duration. (problematic, since can't use phone for anything else then.)
Use database to record options.
Should drop out immediately if conversation if maxState>ringing and anybody quits while we're still ringing! Is that hard to detect? Only if originator drops out for any reason, will do.
1. Do new idlerg case (quit if originator has quit).
2. Do rgck stuff to select a (small) range of values of things to do: key=$multiring
quit right away when anybody answers (drop out) $false
quit after a time when anybody answers (ring until then) $#, representing seconds to ring
keep ringing forever until locally answered $true (intended to be used with timed db entry; Finch can set this, but should set so it has to continually renew. Finch should also be able to put call in some non-ringing limbo state (inactive) until answered or something. Finch could also change the tune and # temporarily, and allow ringing to continue (has been answered though -- how to get anybody to notice the changed tune????) Hmph.
Default: $false.
3. Do we need a way to suppress answer for a tad so Finch can deal with what answering means, too? deferringing, deferanswer should be separate values. Not yet. Would even like to be able to suppress going idle when others quit. Would allow Finch to keep connection to voice server alive. Maybe should support this one. Problem is it's a bugger to do on a timed basis. Not yet.
4. deferanswer should affect Rejected calls, allowing Finch to manage multiple calls, select among them, and so on.
Try to arrange for visiting to "take" while ringing is in progress! That takes special-casery. Visit command searches around for that particular state and does an Alert?
If A visits B, then B phones A (making B busy), current result is that B's Finch doesn't get an abandoned line (??), and also the ring tunes are as if A phoned A; and B gets no ringback tone at all -- bug. Absence of narcissism testing in the 2d notify case? Appears no longer to be a problem, as of December 22, 1986 2:33:35 pm PST.
Foo. Narcissism is caught at GetParty time. It should happen only at Alert time, and only if all attempts to notify were unsuccessful. Maybe narcissism should be detected and generated only by the called smarts? That's a more radical move. December 22, 1986 2:32:56 pm PST Now narcissism is detected in ThPartyOpsImpl.AlertOne. Allows one of called parties in a visiting situation to be busy while others ring.
June 19, 1986 11:14:21 pm PDT
Thrush?
Maybe the first key table distribution should be done by report? Would be a lot cleaner than present LarkSmartsSupImpl scheme. Look into it.
December 20, 1985 4:41:30 pm PST
December 19, 1986 9:52:09 am PST Obsolete -- Service Registration
Finch
(optional) Would still be nice to have Finch <-> Lark communications. DB model, remember. For instance, to capture partially dialed numbers.
March 2, 1986 11:41:58 am PST
December 19, 1986 9:52:34 am PST obsolete
VoiceRopes
Voice Ropes: short expiration possible, as well as the two week kind.
January 30, 1986 5:47:28 pm PST
December 19, 1986 9:53:13 am PST obsolete
VoiceRopes
At present, WalnutVoice will make a voiceFileID entry when a recording is made, and then retain it even if the message is never sent. In the voice ropes design, there needs to be a way to avoid that and make it available for collection immediately. Possibly an expiration-interest, which starts out set at an hour and is boosted to two weeks just before sending.
November 16, 1986 5:52:44 pm PST
December 19, 1986 9:43:37 am PST obsolete
Thrush
Can something like conversation notification be used to keep Finches and Thrushes in tune about who's running? Error stuff.
November 26, 1985 4:09:21 pm PST
December 19, 1986 9:47:14 am PST obsolete
Bug: Unsnarled a monitor lock when locked registering routine reported something via TU which uses DescribeParty which is locked, too. Unsnarl Deregistering stuff of a similar ilk. Why is DescribeParty locked anyhow?
November 26, 1985 4:09:21 pm PST
December 19, 1986 9:47:02 am PST obsolete
Thrush
Monitor-lock what's necessary in Party/Smarts creation. Maybe everything.
July 7, 1986 6:02:37 pm PDT
December 19, 1986 9:47:55 am PST
Thrush/Finch
Why can't failures be treated as user-generated events? Main problem is that failures want to make things go away, but sometimes while others still believe they exist. Sigh.
April 27, 1986 6:45:47 pm PDT
December 15, 1986 5:12:09 pm PST
Thrush
When a Lark fails and does not reload — at least before some LarkOut outgoing call detects the failure — recovery does not happen at all right:
Doesn't unregister.
Next attempt to contact that Lark leads to raising of LarkFailed, and nobody catching it. This stuff should be real easy, and it isn't. Why? Guess this shouldn't be surprising, since I have on the list the fact that error management is a mess.
November 26, 1985 4:09:21 pm PST
December 15, 1986 5:12:19 pm PST
Thrush
Still need quicker timeout LarkSmarts->Lark. Party -> FinchSmarts can now take longer.
November 26, 1985 4:09:21 pm PST
December 15, 1986 5:12:27 pm PST
Thrush
Why is LarkFailed never mentioned in LarkSmartsSupImpl? And Deregister.
June 22, 1986 9:14:55 pm PDT
December 19, 1986 9:49:02 am PST obsolete
Thrush
Need some diagnostics for reportsOutstanding stuff. Count # remaining in each Party, maybe log the calls as they're made or something. Something's getting lost when things don't shut down just right.
March 2, 1986 11:42:24 am PST
December 19, 1986 9:49:49 am PST obsolete -- VoiceRopes
Intervoice
Better Intervoice errors, instead of or in addition to "Complain". Complain is convenient for them as don't want to handle errors, though.
February 2, 1986 1:21:03 pm PST
December 19, 1986 9:50:05 am PST obsolete -- VoiceRopes
Intervoice
Intervoice.Open.Complain should include an ec atom, as well as the complaint. Can be ignored for now. May also want Intervoice.Error (or have it in place of Complaint), with same parameters.
October 19, 1986 2:46:01 pm PDT'
December 19, 1986 9:51:43 am PST Terry
BluejaySmarts
Multiple-interval ropes don't work on playback. The connection shuts down too soon, then subsequent attempts to play are fouled up. When the connection is held open by the speaker switch or the handset, things work fine. Here's what's happening:
1. Ropes are requested by unique ID, but tune intervals are scheduled for reports. The same unique ID is reported $scheduled, $started, and $finished more than once, internal to the playing of the rope. The first $finished shuts down the connection. Will try to find a way to avoid that, but it's not real easy. Introduce concept in BluejaySmarts of "firstInterval" and "lastInterval", and the notion that some events are only reported for former-style intervals, and some only for latter-style.
2. When the conversation shuts down, remaining reports are stranded. They don't just effervesce, probably because of the hair surrounding reports coming from Bluejay. Not sure how serious this is. Perhaps they eventually flush out without further damage. This has been partially corroborated. If the next conversation connects to the smarts before the old conversation has been deleted, the reports get through to the Finch, too. They probably shouldn't.
3. In general, shutdown of Bluejay connections isn't too clean. When things are aborted, esp. by closing the conversation, buffer VM appears to be released before everybody's done with it, and like that.
December 17, 1986 5:15:32 pm PST
December 17, 1986 5:15:53 pm PST
LarkControl
Change so that it always looks on root directory for all files. That's not good, but it's better than when it was random.
November 25, 1986 3:33:04 pm PST
December 19, 1986 9:26:05 am PST
Thrush
Revise registration, failure, failure management and recovery at the Lark level.
Some things are still not wonderful about the error management:
Have not installed the RPCRuntime that knows how to fail quick. Haven't fully tested the fail-quick stuff anyway, because of a ML deadlock.
Looks like the EventTimer timeout is now hair-triggered. Apparently messed something up in the LarkB software, and now it times out instanter if not inhibited. Should be set to fire after the RPC timeout fires, the latter being indicative of a more serious failure.
Think about changing how Extension works. Use the database?
Can change offhook checking at startup to require another onhook input event to enable. That should clean up/eliminate the multiple callbacks.
Failure and Lark inputs are identified by some unique epoch value so that old failures won't kill off new Larks and Smarts. The old incoming conversation handle is enough, but must now be remembered somewhere. Used just SmartsID, as it turned out.
Can use smartsID (Lark's) as the epoch value. Although the actual conversation ID would be more guaranteed unique, the statistics are very much with us. Simplest process is to make deregistration atomic enough that a registration will either cause or follow a failure, not intermingle with it. Then don't absolutely require a continuous MBQueue for the Lark. Safer is to go ahead and use a continuous MBQueue (via a last-used larkInfo!) for a Lark. Let's do that. LarkSmarts registration code has to include MBQueue as a registration value. Continue to have Fail be a separate operation, guaranteed to precede a registration if necessary.
Find out how to do registration, where the smartsInfo doesn't exist yet. How did we even find the right larkInfo? Answer? we didn't! Have to create a new one, and then we don't get serializability on the old one. Yuk.
recovering state isn't used; eliminate it and the tests for it. Perhaps failure should be a separate bit, not a state, so code doesn't have to check for it everywhere. Keep it internal to LarkOut? Right; remove failed state, too.
Registration, failure, and Lark inputs are all serialized events.
Use an MBQueue at the LarkIn level to serialize all the events. Use a single MBQueue for both Lark and Trunk. All queued procedures are entry procedures. Different procedures are queued for trunk and Lark actions! Perfect!
Registration out of the blue produces a failure event followed by a registration event, if there's an old smarts around.
LarkOut calls never fail. If they find the Lark disabled, they ignore the call. At the point where the disablement is discovered (failure state set), they issue a failure input. If the failure does not imply that the Lark is obviously dead, may be worth trying to queue up one additional "go idle" request to the Lark? They are allowed to fail in the sense that they can issue "Problem" calls, to aid in diagnosis.
Input events that can be handled directly at the LarkIn/Out stage should continue to do so, but watch for deadlocks. Look for ways to clear up the confusing up/down/up/down nature of the CheckHookState stuff.
Consider a more efficient way to map Larks to their LarkInfos than the host number triple? Not sure this problem will come up, except during registration, to identify old versions.
OK to do debugging and error printout in LarkOut, but not do any normal-operation logging there. Include reason information for failure in the Failed event, or otherwise log it.
Ignore old smartsID and epoch numbers in Registration.
The only way to kill a lark is for LarkOut to timeout or for LarkOutImpl.Fail to be called, which marks the Lark out of service, issues a Failed input event, and causes the smarts and parties to go away. In response to the Failed event, it's always OK to take down everything without any further attempt to communicate with the Lark -- attempts that are made will be ignored!!!
LarkControl should be notified (clean up remotecontrol stuff) when a Fail occurs -- at least if the Lark's operational. RemoteControl stuff was clean enuf as is.
Should be a way to synch with LarkOut when desired. Or maybe LarkOut queueing should happen at a higher level? Anyway, key distribution synching is a kludge, and also want to be able to get initial confirmation that a phone is there before ringing it. Next item might take care of that.
Want a way to poll phones occasionally, whether idle or otherwise. Can possibly do from a separate process. Maybe should also do from inside supervisor, while a call's in progress! Yup. Then don't worry about the "are you there" thing. The answer will be correct often enough. Polling is done by supplying REF BOOL as argument to QueueLark..., iff there's nothing on that Lark's queue. LarkSupervisor changed to zap its process right away when the queue is empty and the Lark's state is $idle, so that the processes spawned by this polling do not persist.
(Work harder sometime to do all state-change rejection based on mutual exclusion (lark/trunk) at this level. Talking about front door/back door limitations.) [Moved to own entry.]
Inputs converted to SlackQueue form? Not yet.
November 22, 1986 5:01:10 pm PST
December 15, 1986 9:43:30 am PST
Thrush
Eliminate all the BTree and BTreeSimple stuff from ThNet and Thrush.df
November 22, 1986 3:21:26 pm PST
November 24, 1986 9:18:14 pm PST
Cedar
Need a way to control the timeout behavior of individual RPC calls. The proposal is to add a maxTimeouts field to the ConversationObject in RPC, use it when non-zero to control timeouts in RPCPktIO.PktExchange, and add an interface to set it. Will require own version of VoiceUtils, since NamesGVAuthImpl imports RpcInternal!
1. Produce own version of RPCRuntime (again) to /voice/voice/dcs/, install in basic.loadees, make a checkpoint, make sure the system runs (try Walnut). (60)
RPCPktIO knows about the concrete value for conversation handles.
2. Produce own version of VoiceUtils, just to accommodate. Try to minimize excess files. (60)
3. Make Intervoice.
4. Make Thrush, LarkSynthesizer, Bluejay if necessary.
5. Make Finch, FinchSynth, whatever.
6. Experiment with timeouts.
7. Implement a timeout to Larks of 4 for operational Larks, something very large for others. Or
extend the model to include the "don't do it" flag. Want a way also to force timeouts when
debugging, or to inhibit timeouts when operational, based on parameter settings. See LarkOutImpl.pd for settings.
8. Experiment with different values for the Lark to server timeout.
9. Implement the best of those timeouts for operational Larks, "don't do it" for others. Want to do this only at machine initialization, so it may be tricky.
October 2, 1986 6:42:37 pm PDT
Thrush
Convert WhitePagesCNF stuff to LoganBerry, dammit.
November 24, 1986 6:57:23 am PST
VU
Change the way VU works. Have everybody register on a list so that when VU is issued, you get all those. If you join the list when it's in effect, you add yourself?
October 13, 1986 9:23:34 am PDT
All
Impose a notation for $nb-assignment, and possibly use. Write a program to generate a registry of nb codes, where assigned and where tested. See if existing cross-reference stuff will help. Put it in a Loganberry database?
August 9, 1986 3:22:26 pm PDT
Thrush
Need a test suite -- manual stuff to do to test specific cases.
June 27, 1986 10:07:59 am PDT
Lupine
Recent observations:
UnimportInterface is not "SAFE" in control interfaces. It is in the impl, so it's a bug.
All procs should check "bound" and raise Unbound if not there. Otherwise, clients have to catch VM.AddressFault and assume that means unbound.
Consider having Lupine and RPC.StartCall do the checks for unbound and work together to do imports automatically, assuming that some default values are around from last time or something. Allows automatic recovery from server restarts, failure to reconnect after rollbacks, and so on.
Lupine needs to combine BinderImpl with ClientImpl, implement BinderImpl stuff only for multiple-imports interfaces, ClientImpl stuff only for single ones, provide a local interface record as part of what ServerImpl does (result of an import on the same machine!, or maybe a separate optional procedure that returns NIL if it can't be done?), eliminates all the non-relevant stuff, like Interface records for single-import versions and such.
April 27, 1986 6:38:44 pm PDT
January 16, 1987 3:09:04 pm PST
RPC
RPC failures are frequent when caller and callee are on same machine. runtimeProtocol errors, mostly. Wonder what it is? Found specific bug where a to-caller packet was being treated as a to-callee packet, and fixed it. Problems are now reduced or non-existent.
December 16, 1986 5:58:01 pm PST
December 16, 1986 5:58:06 pm PST
Lark
Spent a couple days fighting an unwillingness of Larks to stay up when there was more than one of them using the new software. Making a very long story very short, Since last May Larks have been willing to accept broadcast bind requests on the RPC socket, responding to them with an RFA. But typically only one, far as I can tell. This was bad anyway, because if the response got to the broadcasting lark before the Dorado server's response, the Lark would fail to bind to the Dorado -- the intended result. Somehow, when a Lark was tuned to the current "Thrush 7" server, it responded with multiple RFA's, tying up one of the RPC server processes in the Lark. After this happened three times, all three processes were tied up and the Lark could no longer service requests. Timeouts and other nasties were the inevitable result. I removed the explicit test that allowed broadcast packets through the EnqueueRecvd filter in RPCPktIO, and all is well. We'll probably never know why the Lark was in a sufficiently different state after registering with the new Thrush to behave differently.
December 9, 1986 9:08:04 am PST
December 15, 1986 5:08:41 pm PST
Lark
It's likely that lark event timeouts don't work any more.
December 8, 1986 7:02:38 pm PST
December 15, 1986 9:40:21 am PST
Thrush
When connection goes down due to Lark failure, it isn't idled in a way that produces an error tone on the other end.
December 8, 1986 6:47:46 pm PST
December 15, 1986 9:40:41 am PST
Thrush
key distribution: when Lark fails, it must release anyone waiting for key distribution.
October 13, 1986 9:06:58 am PDT
Finch
More prose stuff.
Breakup function is now available to FinchProse clients, not done by FinchProseImpl.
SynthesizerServer is the service interface.
Rename FinchProse => FinchSynthesizer.
One rope at a time into FinchSynthesizer.TextToSpeech.
ConvID treatment like the recorded-voice stuff.
September 23, 1986 3:06:18 pm PDT
Finch
Installing text-to-speech. Pulling functions from FinchSmarts to separate FinchProse interface. Eliminates ability to get at these functions through FinchProcs. Doug and I have pretty much decided that FinchProcs are unnecessary anyway; we can insist that low-level FinchSmarts stuff always be included if any of the code it depends on is to run. Can reverse this again if necessary, later.
Pulling Recording stuff out and using it as a prototype for prose stuff. New interfaces and impls: FinchRecording(Impl), FinchProse(Impl).
Must call FinchRecording.InitializeFinchRecording[] before calling its procedure!
Doug: Why does ReportRequestState have two arguments, the second of which is always NIL?
August 31, 1986 1:26:42 pm PDT
All
Reinstate DecTalk code (with hooks for Prose).
How it works now:
ThParty.SetProse: do some checks, call PostConvEvent to record the scheduling of the list of proseSpecs, insert stateID's, issue ThPartyPrivate.Supervise[] for all parties in the conversation (Wachet Auf.) This results in ThSmarts.Progress reports to all participants. This happens whether the SetProse is for request, started, or finished.
October 19, 1986 5:57:24 pm PDT
Thrush
Party-level reporting still messes up when reporting times out or otherwise fails (typically due to RPC problems in same-machine situation, during testing). Symptom is that reportsOutstanding counts for conversations (reports are distributed across smartses) don't go to zero. Does deregistering a smarts clear its report queue? If so, that would explain it. Need to avoid deleting smartses that are still active, or at all, or something.
There's a direct cause for this problem: DeregisterSmarts zapped the progress queue, without accounting for its counts! Dats a no no.
Here are the Celtics Breakpoints in ThPartyOpsImpl to try to track this down:
17734 Check Idle
16156 Q Entry
24964 Q Final
24461 Action
21531 Subst
17344 Progress
17595 ReportCheck
24299 No Action
21464 No Subst
17277 No Progress
Also put checks after all three report calls, to track things down.
Check Idle = Q Entry + Q Final = Action + Subst + Progress + ReportCheck
Here are the BreakTool Breakpoints to try to track this down:
Current breaks:
Current breaks:
Break in ThPartyOpsImpl.DoReportAction (pos: 24299)
(expr: &msg["No Action", LOOPHOLE[report.smarts, CARD], conv.numReportsOut, "\n"])
Break in ThPartyOpsImpl.DoReportAction (pos: 24461)
(expr: &msg["Action", LOOPHOLE[report.smarts, CARD], conv.numReportsOut, "\n"])
Break in ThPartyOpsImpl.ReportSubstitution (pos: 21531)
(expr: &msg["Subst", LOOPHOLE[report.smarts, CARD], UnsealConvE[substReport.convEvent.self.convID].numReportsOut, "\n"])
Break in ThPartyOpsImpl.ReportSubstitution (pos: 21464)
(expr: &msg["No Subst", LOOPHOLE[report.smarts, CARD], UnsealConvE[substReport.convEvent.self.convID].numReportsOut, "\n"])
Break in ThPartyOpsImpl.CheckIdle (pos: 17734)
(expr: &msg["Check Idle", conv.numReportsOut, conv.numIdle, "\n"])
Break in ThPartyOpsImpl.ReportProgress (pos: 17344)
(expr: &msg["Progress", LOOPHOLE[report.smarts, CARD], UnsealConvE[convEvent.self.convID].numReportsOut, "\n"])
Break in ThPartyOpsImpl.ReportProgress (pos: 17277)
(expr: &msg["No Progress", LOOPHOLE[report.smarts, CARD], UnsealConvE[convEvent.self.convID].numReportsOut, "\n"])
Break in ThPartyOpsImpl.ReportToParty (pos: 16156)
(expr: &msg["Q Report", LOOPHOLE[pSmarts, CARD], HowToReport, conv.numReportsOut, "\n"])
October 19, 1986 5:13:52 pm PDT
Bluejay
Some more ropes to play with:
Swinehart.pa#593268694 ABCDE
Swinehart.pa#593268738 FGHIJ
Swinehart.pa#593268762 KLMNO
Swinehart.pa#593268822 FGHIJKLMNO, cat 2,3
Swinehart.pa#593268847 ABCDEFGHIJKLMNO, cat 1,4
Problem here was that some concatenation and substring operations yielded white noise (no key). There were two problems: substring could produce a rope that did not begin on a block boundary; concatenation of two ropes with the same key could call RegisterKey in a way that inhibited reports. Fix was to decouple key registration from the reporting, which is now launched by BluejaySmarts.
October 17, 1986 1:51:45 pm PDT
Bluejay and friends
Set Trace BluejaySmartsImpl.DistributeKey [source: 6224] [pc: 3680] Before distribution
Set Trace BluejaySmartsImpl.DistributeKey [source: 6571] [pc: 3818]. After distribution ack
Set Trace LarkSmartsSupImpl.LarkReportAction [source: 5788] [pc: 2922]. key rept. to lark
Set Trace BluejaySmartsImpl.ReportAction [source: 4526] [pc: 3331]. distr. ack coming in.
Set Trace LarkOutImpl.EnterLarkSt [source: 7383] [pc: 3497]. Queing key table for lark
Set Trace LarkOutImpl.EnterLarkSt [source: 7446] [pc: 3531]. After key table sent, in EnterLarkSt
Set Trace LarkOutImpl.LarkSupervisor [source: 12500] [pc: 4972]. After sent, in LarkSup.
Swinehart.pa#593070694 doug
Swinehart.pa#593091270 me
Swinehart.pa#593093911 cat prev. two.
Swinehart.pa#593177782 me
Swinehart.pa#593177868 cat prev. two, inverse order
What's this all about: setting spy traces at these points on this date tracked down a (the last) problem in key distribution. LarkOutImpl wasn't properly tying itself and the Lark Supervisor together to be sure keys were out to the Lark before returning. They will, now!
November 1, 1986 5:28:47 pm PST
All
Synthesizer stuff: remaining problem: if flushing, get no finished report these days, so connection doesn't shut down. What did old code do? Otherwise, is working reasonably well. Finish reports were not being generated in all instances. It all seems to work now, except for some confusion about keeping the conversation open and one experienced with a "picked bit" in an ActionID.
October 29, 1986 12:38:00 pm PST
All
Finishing up Prose reintegration. Discovered a problem with DescribeParty, party name field, nameReq. Doing a complete analysis of all the disparate uses, and the funny service business in GetParty. (translate to RName and fix it up in DescribeParty is current suggestion). Here are the relevant things and where they appear.
% .name
ThPartyInitImpl.mesa!20
TUImpl.mesa!1
% name:
ThPartyInitImpl.mesa!20
% GetRnameFromParty
thrush>ThPartyInitImpl.mesa!20
thrush>ThPartyOpsImpl.mesa!23
% DoDescribeParty
ThPartyInitImpl.mesa!20
ThPartyOpsImpl.mesa!23
% DescribeParty
LarkSmartsSupImpl.mesa!18
LarkTrunkSmartsImpl.mesa!1
ThPartyInitImpl.mesa!20
TUImpl.mesa!1
% GetPartyInfo
LarkSmartsSupImpl.mesa!18
ThPartyOpsImpl.mesa
% GetPartyInfo
FinchSmartsImpl.mesa
% nameReq
FinchSmartsImpl.mesa!27
October 22, 1986 8:48:16 am PDT
All
Synthesizer integration
Here are the files involved in Text-to-speech synthesis to date:
/Intervoice/Synthesizer: Interface to common text-breakup procedure; def of SynthSpec.
/Intervoice/SynthesizerImpl: impl of same, replicate in workstations and server.
/Intervoice/SynthesizerServer: Service Interface to the Synthesizers.
/Finch/FinchSynthesizer: Client-level interface to Finch synth. stubs.
/Finch/FinchSynthesizerImpl: Finch synth. stubs; with FinchSmartsImpl, invokes service.
/Thrush/LarkSynthesizer: private interface as needed.
/Thrush/LarkSynthesizerImpl: so far, just the LarkIn/Out Level of the synth. service.
In LarkSynthesizerImpl, can collapse a lot of the LarkIn/Out code, put all the decision-making under the LarkInfo monitor lock, and so on. Don't intend to change the logic or data structures.
In this implementation, client and client markers alternate, one each per request. In the previous version, I'm not sure that was quite true. I'm assuming this is OK.
October 16, 1986 10:21:24 am PDT
LarkOps, LarkB
Add prFlowControl parameters: if TRUE, XON and XOFF are honored in Lark. Defaults to FALSE.
October 16, 1986 9:22:15 am PDT
Thrush
Service party clones were given the wrong party.name values (not a true problem). Service smarts clones didn't have notification queues (a true problem).
October 16, 1986 9:23:29 am PDT
Thrush
unused entries in key tables were not parity-corrected; other failures might cause packets to arrive at a Lark indexing these keys, resulting in key parity error failures in Lark. Now new key tables are initialized to parity-corrected null keys, unless pd.
August 9, 1986 3:23:51 pm PDT
Finch
Way for finch to tell Thrush not to reject an extra call out of hand, using timed-persistence. Similar to solution in August 7, 1986 5:19:44 pm PDT for how long to ring the visitor home site or visited site after the call's been answered at the other site. Nope. This is just a case of the $deferanswer mode; Lark won't answer the first call or reject an extra one until the $deferanswer mode has timed out and been cancelled.
November 26, 1985 4:09:21 pm PST
August 9, 1986 3:25:33 pm PDT
Finch
P: more reasonable way for Finch to influence call progress without disposition.
(only interesting time: notified. Finch can tell Thrush not to go into ringBack, or to reject an
extra call, for some number of seconds. During that time Finch can make its own decisions.
If the timeout ever occurs, this condition is removed. !!!!)
August 5, 1986 10:42:51 am PDT
August 7, 1986 5:19:44 pm PDT (abandoned to August 7, 1986 5:19:44 pm method, above)
Thrush
Doing Visiting incrementally:
Add ThParty.Visit and ThParty.Unvisit.
Only $individuals can be visited.
Visitors can be $individuals or $telephones.
Almost anything will cancel visiting, including call-initiation from visitor home site.I
have by no means identified all the combinations that can occur; some of the attempts to
cancel visiting don't work at all. Probably because some of the methods for cancelling
Poaching don't work at all, along with specific bugs. Probably should guts it out and deal
with all the cases.
When visiting is cancelled, substitution has to occur to keep the call alive. I have no
confidence in the implementation; should leave things stranded sometimes. Try at least to
unvisit before cancelling poaching; will cause two substitution reports but might work, ??
$individual visitors, $individual and $telephone visitees get progress reports. $telephone
of visitor, whether direct or $poachee from $individual, does not.
Try to arrange for visiting to "take" while ringing is in progress!
Now consider multi-ring options and the like. Requires both database and all-in stuff.
May 1, 1986 10:21:06 am PDT
August 7, 1986 3:41:40 pm PDT
Thrush
Implement simple Visitors version. Then worry about multi-ring version (change in party/conversation membership structures involved?)
November 26, 1985 4:09:21 pm PST
Thrush
Cause $visiting to be inherited as parties die and resurface. Worth it? No.
August 5, 1986 10:40:52 am PDT
August 5, 1986 10:42:58 am PDT
Thrush
Added ThParty.UnregisterKey, which decrements a reference count that ThParty.RegisterKey increments. Zero-count keys are removed from the list. This requires a slightly different approach to searching and entering keys, since the table can now be non-contiguously allocated.
February 16, 1986 2:49:39 pm PST
July 17, 1986 2:03:10 pm PDT (actually, much earlier)
The duration of a feep should be adjustable, esp. during a call via Feep command. For controlling inadequate stuff. Also, it should be an option whether feeps are audible; during dialing or otherwise, I guess.
June 22, 1986 9:08:39 pm PDT
July 16, 1986 9:35:17 am PDT
Recording/Playback
Things left to do:
Clip around recorded stuff in RecordPlayImpl.
Get TiogaVoice working?
Check out remaining flakeys.
June 28, 1986 10:41:25 am PDT
July 16, 1986 9:18:04 am PDT
Thrush/Finch
Implement the hack that lets Finch decide whether to answer calls, defaulting (permanently) to the standard behavior in small numbers of seconds.
Design:
gvnames.<user>.pa.lark.deferanswer: <n> enables. Finch just writes it. <n> is number of seconds, but lark code can also impose a limit.
LarkSmarts just forks a time bomb with timeout <n>, which acts when after timing out the conversation still exists and is still in state notified. Acting is defined as clearing the deferanswer entry, and entering ringing state (or whatever QdNotify does.) Perhaps need not clear deferanswer, since that could be set by below facility.
Finch: add some simple filter function to decide whether to accept or reject call. Immediately see the need for ways to control things like ring tune, ringing mode, ..., on temporary basis. Then Finch can set ringing to subdued, change the tune, whatever, then enter ringing state, modifying ringing on call-by-call basis.
Requires a way to set temporary values for any gvnames value, as a universal facility. Timeouts specified by same sort of <n>, stored as expiration time. For all lookups, GetAttribute first searches for $timed.attribute, then $attribute itself. GetAttributes should probably select $timed.attribute over $attribute, converting to $attribute. Need separate SetTimedAttribute call to store, overrides any other. Will require release to Thrush, so contemplate Extras interface.
Convert the ringmode stuff to use this general facility.
This works very well. Shared persistent storage, with timeouts, is the way to control a simple application from a complicated but possibly flakey one, so that the simple one can backstop the more elaborate.
June 22, 1986 7:22:42 pm PDT
July 7, 1986 5:54:19 pm PDT
Finch
Starting a WalnutSend recording with the phone on-hook did awful things last time I tried it. Try again after everything else works.
June 12, 1986 5:44:24 pm PDT
June 25, 1986 9:13:10 am PDT
Finch
PlaybackTune used to do the silence-shaving, and now it doesn't. FinchSmarts must include a coupling to the interval-description stuff to do that. See example of simple shaving (just after recording) in RecordPlayImpl.
May 1, 1986 10:22:35 am PDT
July 16, 1986 9:24:35 am PDT
Thrush
Finch should be able to control LarkSmarts acceptance of calls by:
LarkSmarts told not to proceed from Notified to Ringing, but to react to Finch doing it. Timeout: small numbers of seconds. Telling is done in the database. Timeout causes the database to reset. Finch is now responsible for pushing the call into a more stable state within the timeout interval. See updated design near above completion date.
January 25, 1986 3:41:03 pm PST
July 16, 1986 9:25:52 am PDT
VoiceRopes
Have agreed to revise Nuthatch to use a server-based Loganberry database. Steps:
Analyze present Nuthatch logs and code to determine the format of the database, how many logs, ....
Implement a local-machine version. Use a local jukebox and private server.
Change to run on server, test on same machine. 5
Work out directory issues (separate naming scheme on top of Loganberry). 4
WalnutVoice can have an argument, which is the base name for a database. Default is ///<serverRoot>/tunes, identifying ///<serverRoot>/tunes.df and ditto/tunesRefs.df. <serverRoot> is whatever server one is looking to for Thrush services. There should be a default Complain procedure, too, and eventually a default interpretation for what happens when a handle is NIL (do the appropriate open, using the default). Defaults are invented at the Intervoice level. VoiceDB is in some ways not an interesting additional interface. Local default is ///users/<userRname>/temp/<serverRoot>.df and so on.
Build a simple garbage collector!! Work out backup methodology. (via enhanced browser?) 8
Work out conversion methods from present system. 7
Consider building a local/remote standard Loganberry-based package that writes locally if can't write remotely, consults local if exists. When can write remotely again, enumerate the local database into the remote one and delete the local one. 9
February 2, 1986 9:43:43 am PST
July 16, 1986 9:26:20 am PDT
VoiceRopes
VoiceDB really should be a general local/remote reopening interface to Loganberry, with the specific semantics pushed on up into RecordPlayImpl? If it weren't for GFI's and the fact that files = modules, I'd probably put another level in there.
December 2, 1985 12:30:27 pm PST
June 25, 1986 11:35:13 pm PDT, abandoned
Utility
Consider a command that clears all triples, flushes the RefID cache (hard), flushes the conversation cache, and any other state saving values. Then could restart even when per-each restart code didn't work.
June 28, 1986 10:35:32 am PDT
June 29, 1986 12:37:48 pm PDT
Finch
BD incoming calls when FD is off-hook now fail once per ring cycle. That way the callee can hang up and get the call on the next ring. Finch records each attempt separately. A short-term solution is for Finch to do something similar to its current entry-reuse heuristic when successive unanswered BD calls come in within a short interval. Turned out the test is for subsequent calls that reach $notified but not $ringing within a small interval is the right test. That's nice, because it means that calls that do ring don't have this behavior and get treated separately!
June 28, 1986 10:31:07 am PDT
June 29, 1986 11:22:32 am PDT
Thrush
$voiceTerminalBusy stuff still too aggressive. Suppose A, who has a Finch running, is on an outside line or his BD is tied up for some other purpose. B calls A. Still want A's Finch to see the call attempt, although it should fail immediately as the attempt occurs. The things we want to prevent are:
A, picking up the instrument when A's BD is doing something else, fails to get anything.
Ditto attempts to call from A's Finch if the BD of choice is doing something else (want multiple choice, though.)
B actually succeeding in calling A under similar conditions. Attempts to call A when A is truly busy do not have to be handled this way!
Perhaps all of this can be done in the Advance/Verify code, and none in GetParty. Even with a PartyAvailable[] removed from GetParty, B still fails before contacting A or A's Finch in any manner.
Truth is, this is better handled at the Smarts level. At ring-detect, off-hook, or being-notified, check hook state and if it's inconsistent, ignore first two events, turn down connect attempt in third instance. Then remove all the PartyAvailable stuff from the rest of the world. Make sure that hanging up after trying to come off hook is properly ignored, though. Probably will be, since state will be idle or so. Did it that way, and it worked. Have to remove the junk from Party level.
June 28, 1986 10:30:04 am PDT
June 28, 1986 10:34:58 am PDT
Thrush
GetParty was too aggressive when the destination party was $voiceTerminalBusy (already had a back door call). That caused attempt to use own Front-door party to fail, and to go on to try to use the back door. Confusing, and not useful.
June 22, 1986 9:09:33 pm PDT
June 28, 1986 10:29:11 am PDT
Finch
When other conversations intrude and are rebuffed, the selection goes away. It shouldn't. That was due to a database foulup where two workstations each thought they owned the Finch. Little wonder I was confused.
June 19, 1986 11:49:36 pm PDT
June 29, 1986 11:42:09 am PDT
Thrush
Problem: reports don't always finish, and I can't find the outstanding call. There's some other problem that's killing off Finch, now that auto-shutdown is a possiblity. Wonder what it is? This is all tied up with the fact that there are lingering Party connections. That's because some reports haven't finished, or think they haven't. Is that because something's tied up on monitor locks? I wonder. The results are not pretty. Something keeps both parties in the conversation, and I don't understand that. This seems to happen when new conversations are started before old ones have completely died? Or something? This doesn't happen every time. Also, somebody is treating these as live conversations, even though all parties are idle. Like Bluejay repeatedly reports the conversations's death, at times when that conversation should not even be involved in anything. Major cause: when parties failed, outstanding reports were abandoned without either decrementing the count or doing the CheckIdle check that zaps conversations. Expect to see many fewer of these in future.
June 20, 1986 6:17:25 pm PDT
June 21, 1986 4:25:06 pm PDT
All/Bluejay
Ugh. Should either indicate with different finished report that all is $finished, not just the current piece, or should include a $scheduled event when an event is first accepted by Bluejay. Prefer former. To $finished, add $allFinished. But what to do now about $flushed? Possibly there should be a slight delay before shutdown when encountering this value. But that's hard. Also, the assigned intID for a request doesn't make it back to the requestor, so the later matchups are wrong. It was one of those "didn't copy a ref you should have copied" bugs. On the other front, to deal with flushed properly, will issue $scheduled report when $started will be delayed. So it's $started the first time, $scheduled as the others are scheduled when the piece queue is not empty, and $started later on as the pieces begin to play. Only those who have never heard of the events before need to deal with $scheduled. Final design: $scheduled is issued as every interval is requested. $started is issued ditto, so there is a $scheduled/$started pair at the beginning of each recording and playback.
June 20, 1986 0:05:19 am PDT
June 20, 1986 6:16:00 pm PDT
Bluejay
When a piece has been entirely scheduled, so that the server can go on to the next piece, the previous piece may well not have been fully played, but we've made the report already. There's buffering downstream of the report. Have to locate the place where the information played due to one piece has really all been send out (or in recording a fixed interval, when the interval has been exhausted and all that flushed to disk.) That won't be easy. That's false. Finished is reported at about the right time.
June 19, 1986 11:14:21 pm PDT
June 21, 1986 4:52:47 pm PDT
Thrush
Since LarkOut uses a separate process to communicate with the Lark, keys may not be fully distributed when the Report that says they are has returned. Have to develop a way to determine when the key has actually and truly been distributed. Just lock EnterLarkState and its supervisor together with a condition variable. Detect when it hasn't happened before we lose interest at 3 seconds.
June 19, 1986 11:14:21 pm PDT
June 20, 1986 6:17:35 pm PDT
Thrush?
Shut-down when nothing left to play or record and in speakerphone mode. Finch best knows the score about nothing left to play, but LarkSmarts knows whether off-hook or not. Now easier, since reports are more reliable. In reports, record last-seen $started in cDesc, wait for $finished or $flushed mentioning the same value. If you don't see it, don't shut down -- who cares?. Otherwise, schedule/do directly a simple idle when offhook. Implemented, but Bug in this design. Now don't get $started until the piece begins to play, so it's hard to know when the last one really comes home. See June 20, 1986 6:17:25 pm PDT.
June 19, 1986 8:42:32 pm PDT
Finch
Finch is not waiting to be sure key distribution has been done before issuing a playback for a tune keyed on that key. Have to queue up the request to play in that instance. Means probably should always do so, to keep things semi-reasonable. Question about whether should queue up something that waits to be joggled, or whether queue might be needed for other things, so the request has to be saved somewhere else. Wherever the list of things to do is kept, it should be flushed on conversation end. Maybe the queue should be in the cDesc this time? Do MBQueues finalize to flush? When queued operation fails, it should do flushed event notification? The queued thing could wait, timed, and on timeout, disappear. Didn't do it that way. Just had calling procedure wait one timeout round (fairly long), then give up. One level synch queue. Should work. Not clear what happens if multiple calls of play from different client procs.
June 19, 1986 8:01:09 am PDT
June 19, 1986 8:42:26 pm PDT
Finch
Reporting of start/finished doesn't get reflected in FinchTool window. Why? Should happen, even though FinchTool didn't know about the thing in the first place. Report procedure wasn't being registered.
June 18, 1986 0:55:36 am PDT
June 19, 1986 7:57:20 am PDT
Bluejay
Bluejay doesn't work, at least for recording. Also, Lark is not transmitting packets to Bluejay or anyone else. Not clear what's with the Lark. That's quite possibly why Bluejay isn't recording any Chirps. Not sure why it doesn't record silence. Ugh. Still had some fixing to do from the change to the Pup package requiring system assignment of local sockets. Thrush has to assign all the socket numbers by allocating ephemeral sockets. Then ThPartyPrivate has to export a GetPupSocket function, which Bluejay can use to find the actual socket structure, since there's no procedure to seek it out, given the socket ID. It is mandatory that Bluejay and Thrush run on the same machine, since these socket guys are shared REFs. Works now.
June 17, 1986 9:37:36 am PDT
June 19, 1986 7:58:34 am PDT
Lark
Out of sockets 400A error arising frequently. What could have happened to do that? Is it related to the fact that we don't switch socket numbers any more? Check later. Happened at a time when would have expected connection to have been long established, so I don't fully understand it.
Lots of things going wrong. LarkOutImpl apparently no longer Disconnects sockets during a disconnect, presumably figuring the Zap will do it. Zap would have trouble doing that because some of the sockets are still valid over a Zap. Also, since the socket number is now no longer changed between conversations, the beginning of the second conversation triggers the "same socket" check. Finally, after there's a voice connection, everything seems weird.
1. Disconnects should still happen when a Zap's going to happen. Verify that it doesn't, then make it happen.
2. Think about bumping the socket number for a Lark by 1 every time there's a new conversation. Will work iff the actual spec information has been moved elsewhere by then. Separation of church and state argues against. Don't do yet.
June 16, 1986 2:15:33 am PDT'
June 19, 1986 7:58:31 am PDT
Bluejay stuff
When we fail or hang up on a bluejay conversation, it doesn't go away because of reports still outstanding. Find out what they are and zap them. Zapped some, but now something similar is happeniing. All reports empty, but numReportsOut is non-zero. When idled with reports outstanding, what happens?
June 11, 1986 9:26:30 am PDT
June 19, 1986 8:00:02 am PDT
Thrush
See Design note for Server Interfaces: must redo the service-allocation with the timeouts and such as indicated there. Must rethink the DescribeParty stuff to use a different scheme for identifying who has it checked out -- like trunks. See trunks for guidance.
June 9, 1986 7:51:52 am PDT
June 19, 1986 8:00:48 am PDT
Bluejay
Working notes. Report should be synchronous, called with stream locked. Report must include started/stopped/flushed. VoiceStream, impl, client. The Report callee, though, has to MBQueue subsequent actions. Maybe Report shouldn't be synchronous!
Flushing cannot be requested within a piece. Can only be done by explicit call.
Should be able to do reporting within flush routine, and at piece-switch time in the server. Should be able to get a flushed report to conv. before terminating conv. -- will probably be fruitless because other end will have terminated, but later can find a way to get reports through. Error state on such terminations, until the Bluejay goes away, just to get the messages?
On recording, will have to get end point through Describe... path.
June 8, 1986 11:31:56 am PDT
June 9, 1986 7:51:32 am PDT
Thrush
In VoiceStreamServerImpl.Server there's some very strange (2 else 1) code having to do with filling the rest of something with silence. This stuff should all be collected into routines anyhow, but ask Steven about that. No problem. Pointer is at first of two words, must be bumped ahead. Ugh.
June 3, 1986 5:48:13 pm PDT
June 9, 1986 7:51:45 am PDT
Thrush
Should ReportAction take a list of action reports, instead of a single one? makes everything a lot harder. No.
December 19, 1985 1:52:54 pm PST
June 2, 1986 8:41:04 am PDT
Finch
Want to get Feep command back earliest. First example of active-time communications.
June 3, 1986 2:29:11 am PDT
Thrush
One final niggle in RegisterKey -- need to indicate when new, not alone in conv. Only then must wait for key before scheduling tune.
June 2, 1986 5:44:45 pm PDT
June 3, 1986 2:24:06 am PDT
Finch
Service registration and action reporting all works, but isn't very robust. If Finch drops out and restarts during a call, the feep interface situation is for some reason the pits. Naw, simple monitor hangup.
June 2, 1986 7:48:41 am PDT
June 2, 1986 8:57:22 am PDT
Thrush
TU stuff:
"allabout" is sometimes too verbose. Add "about", which doesn't try for closures.
Still need "world" sometimes? Wait on that.
Need "ID xxx" which prints its RefID -- its REF value as a long cardinal.
Ditto need an ID[xxx] function that returns the value of any ref as a LONG CARDINAL. Nope. LOOPHOLE[xxx] will do that.
May 31, 1986 4:15:13 pm PDT
June 2, 1986 8:40:28 am PDT
Thrush
Now Lark depends on Thrush (KeyTable). Lark is much less likely to change often. Should put it back the other way, Thrush depending on Lark for key table.
May 31, 1986 3:06:37 pm PDT
June 2, 1986 7:47:43 am PDT
Thrush
Since the same voice service interface can support multiple smartses, and since the Smarts is not one of the things typically directly available to other parties, have to include the smarts ID (probably disguised as a RefID) in the service registration information. You get it back in the Lookup.
May 30, 1986 11:50:24 am PDT
June 2, 1986 7:47:51 am PDT
Thrush
Document that there can be but one instance/version range of any interface type registered per party at any one time. Latest in wins.
May 30, 1986 10:23:51 am PDT
June 3, 1986 12:10:09 pm PDT
All
As far as I can tell, the key synch problem is worse than ever. Key tables are not now distributed, but requested, and I can't find any indication that the existence of a new key is even broadcast. Need a way to be sure all recipients have the new key before transmitting anything under it. Solve this after feeping works again. Maybe a way to tell whether a given report has been fully issued is the right thing. Maybe even a queued report back to the originator, guaranteed to follow all other reports. Not easy, since reports are by their nature unsynchronized. Read up on object-oriented active databases and LOOPs, and such. Optimization: RegisterKey indicates whether the key is new. Wait-style report isn't generated unless it is. Idea: reportsOutstanding can trigger various actions, depending. One of them is killing off idle parties. Another is generating a "they know" report. Try it. While at it, solve the problem that the key table is finite and small. See ThParty.ReportAction's selfOnCompletion option.
May 29, 1986 2:10:43 pm PDT
June 2, 1986 7:48:02 am PDT
All
New mechanism for communicating with services:
See messages of 29 May 86 18:45:56 PDT and following.
May 25, 1986 7:43:15 pm PDT
Big bounce version done, except that apparently new server doesn't support 6.0 version of Finch (NamesGV import failure!). Test by making sure all EPhones are working, then poaching on PolleZ and trying it out. GVImport, typed directly, works, so I'm confused. It was the explicit export/import stuff. The server doesn't export by number any more, so the Finch importing didn't work. Backed it off to the old Grapevine way, until people bounce.
Big bounce version: Triples, VoiceUtils, Agent, Bluejay, IntelHex, LarkTest, Multicast, LarkControl, LarkPrograms, DirectoryFiles are all in common (6.1 version). Intervoice, LarkRPC, LarkPlay, Thrush, and Finch are separate. Possibly Parameters are separate, since there are changes in GV entry format.
May 15, 1986 2:13:50 pm PDT
May 26, 1986 5:03:10 pm PDT
When doing new Lark, remove KeyTable. Not really -- one of the procedures needs it.
May 15, 1986 5:06:58 pm PDT
May 25, 1986 7:42:30 pm PDT
Tell Hal about puptypes 300B through 322B, defined in TeleLoad.mesa.
May 10, 1986 4:44:46 pm PDT
May 25, 1986 7:42:44 pm PDT
All
Converting to New Communications Package. Here are some questions or comments:
What is the correspondence between the Get timeout in PupSocket and the ticks in PupDefs.SocketMake?
Must go back and copy Lark.mesa from "torelease" to "new DCS" in such a way that LarkRPC and LarkPlay and others can reference the "torelease" versions. Reduces work considerable.
Whenever there is only one version these days, it's the `DCS' version. That was the wrong choice, should be the "torelease". Should fix that one too.
Will remove Lark and LarkPlay from the release, putting important data structures therefrom into Thrush, including ConnectionSpecs, KeyTables, and Tone Specs. Lark and LarkPlay drift back into the server side of the house for now. LarkPlay could come back if tune-creation had to be done from Finch. Do that for the "new" system, only. Release an "old" version of Intervoice that has Lark in it, but the new one (not for release) doesn't? Something like that.
May 4, 1986 11:44:36 pm PDT
May 25, 1986 7:43:02 pm PDT
Thrush, Finch, et al
Need to produce version of released system and of this one that uses BigBounce software. Ugh. Do minimal work on released thing, track things in parallel as they happen in the current development version.
December 2, 1985 12:37:30 pm PST
May 18, 1986 4:36:13 pm PDT
NamesGV
Need to change NamesGV interface to use long ropes next time we're really changing what goes on the server. In general, examine all the RPC interfaces for RPC.ShortROPEs that should be Rope.ROPEs. Has to do with long tunes. Did it for the new world. Do it for the old as the old is re-released fo the big bounce.
April 30, 1986 11:00:36 am PDT
May 18, 1986 4:36:23 pm PDT
VoiceUtils
I added GVSave to GVLarkImpl, but it doesn't help, since when run from elsewhere than the strowger command tool, it writes its results on the root directory. Add parameters somewhere, I guess. GVExport records the working directory, and GVSave/Restore use it.
April 28, 1986 1:18:57 pm PDT
May 26, 1986 5:04:31 pm PDT
DOC
Document changes to Lupine, restrictions on use of errors in multiple-import situations. Release Lupine to BigBounce world.
February 3, 1986 2:28:57 pm PST
May 26, 1986 5:05:03 pm PDT
VoiceRopes
If you select more than one node containing a voice file ID, the selection approach doesn't work (Plays all ID's in the header instead).
February 2, 1986 1:11:18 pm PST
May 26, 1986 5:05:25 pm PDT
VoiceRopes
WalnutVoice command should be re-executable, resulting in brand-new handles everywhere, or the equivalent. No need to close old ones, I think. Avoid doing the things like menu button setup and Walnut registration that wouldn't help if it were done twice. Easier now with better control over import.
January 19, 1986 3:20:05 pm PST
May 26, 1986 1:51:11 pm PDT
Thrush
Bug in Lark code. If a LarkSmarts dies but its Lark doesn't, system now terminates all conversations, which causes other parties to be hung up on. Maybe that shouldn't happen, but that's not the point. What happens next is that the non-failing party's user hangs up, which resets the Lark, which goes into a Loop zeroing the key table, then setting all the keys to correct parity. In the meantime, the network receive code continues to run. If a packet arrives before the key table entry to which it refers (usually 1) has been reset to correct parity, kaboom -- parity failure in Encrypt code. Also, SetKeyTable takes a long time because it does parity correction on all the keys!
Question: does decryption happen before the packet is dispatched to the right buffer? Probably so.
Actions, next time Lark is open:
Add echo server to RAM code OK
Have a value that indicates whether the system's really running, and have the FromNet
code desist from doing anything when it's false. No Need
Key table reset should put a zero-but-corrected value into entry 0, then blt that to all the
others. Or set to corrected-zeroes only on initial startup, assuming that correctness will be
maintained by subsequent key table updates. Updates all, first time only
Calls on encrypt should catch the parity-error signal and ignore it, at least as an option.
At least in this case. It's a CallDebugger, Can't catch readily
SetKeyTable should be assumed to provide as many parity-corrected keys as are necessary.
That function should also be willing to accept fewer than 16 keys and either ignore the
remaining entries or zero them Takes 16, but assumes OK parity.
At present, what this means is that right after hanging up in a case like this, one's Lark
reboots. I don't know why it doesn't happen more often! Oh, yeah, because each user
decides when to hang up and reset, and it's usually after the call's over or something.
Add echo server to ROM code (harder)
Repair slave ROM (DB's, whatever else LY said)
November 26, 1985 4:44:26 pm PST
May 26, 1986 12:09:55 pm PDT
Thrush
Doc: what to put into LarkA.patches to set signalTimeout to FALSE in the Lark so that you can have breakpoints that don't cause the Lark to timeout. How to deal with Multicasting. Once and for all how to set up Etherphone connections (extract and extend from program comments.)
February 1, 1986 1:53:05 pm PST
Next time into Lark code, Call SetInGain(ch,0) before letting Echo suppression change the speficied buffer's attenuation table. Then can change LarkOutImpl back, since no control is a bit more efficient. Collect up Lark changes like this.
December 3, 1985 3:07:32 pm PST'
May 26, 1986 12:03:54 pm PDT
Should go through and eliminate all NetAddress and Machine types in favor of PupTypes.something; similarly with Lark.VoiceSocket. Similarly a naming cleanup on ThParty.PartyInfo is already called for. That's all pretty well regularized now.
November 26, 1985 4:09:21 pm PST
May 26, 1986 5:07:12 pm PDT
Compiler and so on: ROPE, Apply, VAL params.
February 17, 1986 6:08:55 pm PST'
May 4, 1986 11:35:45 pm PDT
Thrush
6. If, then, poacher's home phone is picked up, BD call is hung up. That's because FD and BD hardware aren't adequately decoupled! At worst, should effectively ignore the offhook request. General O2I2 problem is that it has to be understood at so many levels.
Issues:
Which Codec to use.
O2I2, inhibiting conferencing for poacher's home phone.
Did some experiments and determined that it's hopeless to do anything with the front door while the back door's in use. Compromise: trunkForwarding causes the LED on the telewall machine to flash. Offhook for such a machine is ignored. We do a nasty check (under the monitor lock controlling LarkState changes, probably LarkSmart's) when offhook happens to see if the back door's tied up, before generating dial tone. Need to solve a Finch problem, too -- noSuchParty1 or something? Possibly, forwarded calls should disable the party?
Ugh. Suppose front door is in use when poacher tries to use back door. This stuff needs to be caught all over the place. A way to determine that own-self is not in good shape. The only special one though is the telset off-hook one, where own self wants to change state before the other party is consulted? Maybe that one can be handled at Party-level, too?
Bottom-line:
Flash LED when forwarding calls.
StartConversation, Alert, .... return nb=$voiceTerminalBusy when self or poachee has a trunk that's already in use. Similarly for GetParty[$telephone] for a telset like that. Avoid initiating actions involving the front door when the back door's busy -- except for incoming trunk calls!
This gets really hairy. The main routine that implements it is ThPartyInitImpl.PartyAvailable[originator←NIL, party]. It sees if the Siamese twin to party's voice terminal (party or its poachee), if it exists, is busy. If so, $voiceTerminalBusy is raised. This is really a smarts-level function, but I've special-cased in here for now. If the Siamese twin is originator, the error is inhibited, since this represents the standard backdoor-in-or-out-on-same-machine case. This function is called in GetParty, to indicate that the party won't work, in StartConversation, to indicate that one's own terminal is unavailable so can't call anybody, and in Alert, to catch the case where things were OK at GetParty time, but unavailable by the time we tried to start a conversation with it.
Well, it works, but I don't like it. Visitors next.
February 17, 1986 6:08:55 pm PST
May 1, 1986 10:15:12 am PDT
5. Call from poachee phone to poachee home number actually tries to do it, doesn't yield fast-busy. This is like narcissism, and should be prevented. In all narcissism cases, want to end up with fast-busy. For now. Finch should work too; and it should be able to arrange something different though. At present, the request is simply ignored!!
November 26, 1985 4:09:21 pm PST
April 28, 1986 2:20:02 pm PDT (??)
Thrush
When dealing with showstopper, fix up cfRef stuff in places like IdleConversationsForParty in ThPartyInitImpl. ??
January 20, 1986 7:49:44 am PST
April 28, 1986 5:06:45 pm PDT
Finch
Finch Conversation log should indicate whether caller is authenticated or not.
April 29, 1986 2:44:29 pm PDT
May 1, 1986 10:14:27 am PDT
Thrush, Finch
Phoning someone by name who doesn't exist causes no-op behavior in Finch. Right parens is missing from ident. of who is being called. Maybe forwarded outgoing Intelnet calls don't work right. Sure don't seem to any more (when you hang up before the call is complete!) There had to be an explicit check when the trunk for a forwarded call found out that the other end was idle -- no check is needed for same-machine calls, since the telset idle will idle the Lark (ugh!). The test was not including trunkSignalling as a larkState, looking only for trunkForwarding. Now the info.forwardedCall bit is checked instead.
April 28, 1986 2:55:56 pm PDT
April 29, 1986 4:41:33 pm PDT
Thrush, Finch
Outside calls seem to screw up in various ways that they didn't useta. Either from telset or from Finch, if by name. Have cured problem of nonexistent outside party fetching a dial tone. Must change GetParty so that when a number is found via RName, the name field of the resulting party become the RName.
April 30, 1986 11:42:07 am PDT
May 1, 1986 9:08:23 am PDT
Finch
8*.... now has an extra "P" to remove from the number.
April 29, 1986 5:42:23 pm PDT
April 29, 1986 5:54:53 pm PDT
"Phone #" doesn't work from Finch commander any more. Or Finch window. Weird.
April 29, 1986 3:03:41 pm PDT
April 29, 1986 6:17:36 pm PDT
Thrush
Auto-supply of authentication doesn't work any more for outgoing Intelnet calls.
March 2, 1986 11:42:59 am PST
April 28, 1986 2:18:08 pm PDT
Thrush
Make radio, hotline, and monitor mode harder to invoke. In fact, remove them from telephone user interface (monitor mode is now part of speakerphone arrangement.) Put telset, lineA and lineB modes on **7, **8 and **9. Make sure **7 and **8 will work with call in progress, like **0. Make * alone trigger *0 dialing! *0 remains valid by ignoring the 0.
February 23, 1986 3:40:11 pm PST
April 28, 1986 1:37:35 pm PDT
Thrush
Before next release, change PARCPhoneNumberMappings to define its own data type, so that parameters can be release-independent. Try for similar independence for DirectoryFiles.
February 23, 1986 1:50:51 pm PST
April 28, 1986 2:15:29 pm PDT
Finch
PlayNoisesImpl uses PD to control on/offness? (Want way to turn on Rollback nonsense besides at Registration time.) Added NoisyBoot, NoNoisyBoot, TestNoisyBoot commands. They'll work when playing tunes works again.
December 10, 1985 9:52:29 am PST
April 28, 1986 2:14:33 pm PDT
Thrush
It would now be possible to treat a speakerphone click as a flash, and simplify the upswitch stuff, since calls all behave like spkr now. I have discounted this. Don't know what to do about flashing.
November 26, 1985 4:09:21 pm PST
April 27, 1986 9:11:09 pm PDT
Thrush
Put radio, monitor mode back in. LarkInImpl, .....
November 26, 1985 4:09:21 pm PST
April 27, 1986 9:11:18 pm PDT
Thrush
Want to be able to do *7, *1 (or *3, whichever is radio mode) on the fly. In radio mode, still route transmitter to DTMF.
November 26, 1985 4:09:21 pm PST
April 27, 1986 9:11:45 pm PDT
Thrush
Add Thparty functions for obtaining old ConvEvent information. (started) DescribeParty does fine.
April 27, 1986 8:55:16 pm PDT
April 27, 1986 8:59:47 pm PDT
Fixing the next thing reintroduced another bug -- that the descriptions of what happened go away when a buzzing non-call is finally silenced.
April 27, 1986 8:22:15 pm PDT
April 27, 1986 8:47:29 pm PDT
Finch
Once a call has failed, even if beeping (thus not yet idle), Finch disassociates from it, won't kill it with disconnect, doesn't leave it highlighted, and so on. That sounds easy to fix.
February 26, 1986 5:39:57 pm PST
April 27, 1986 8:22:00 pm PDT
Finch
Finch deals with narcissism silently.
February 17, 1986 6:08:55 pm PST
April 27, 1986 9:00:26 pm PDT
Thrush
3. Workstation deregistering shouldn't cause hangup. Otherwise all this poaching splice stuff is silly.
November 26, 1985 4:09:21 pm PST
April 27, 1986 9:03:32 pm PDT
Thrush
How to deal with showstopper:
When finch smarts/party dies, zap smarts, but leave party and attached conversations and poachees.
When conv is dissolved, for each party, if it's got no smarts and no other convs, zap it.
November 26, 1985 4:09:21 pm PST
April 27, 1986 9:04:20 pm PDT
Thrush
$poaching/$visiting chain must be followed backwards to zap when dying (see showstopper tho.)
November 26, 1985 4:09:21 pm PST
Thrush
P: need a way to tell a smarts that its party is gone for some reason. Subsumed into a comment above.
November 26, 1985 4:09:21 pm PST
April 27, 1986 9:04:32 pm PDT
Thrush
P: showstopper: when poacher smarts/party dies, how to represent it to conversation and other parties for duration of call; how to shut down when safe? Have to give up on finding out about calls in progress (didn't have to after all).
April 11, 1986 9:43:18 am PST
April 27, 1986 9:05:25 pm PDT
Thrush
At the LarkSmarts level, the database is consulted to decide whether radio mode should be specified. Radio mode setting/clearing and so on should cause switching to take place immediately. Radio mode becomes audioSource. See also transmitOnly.
April 24, 1986 3:29:46 pm PST
Thrush
during splicing, party.partyActive must be transferred to the new party. party.numConvs must be incremented in newParty, decremented in oldParty. Not sure about things like outgoing and reservedBy. Leave them for now.
April 24, 1986 2:52:53 pm PST
Thrush
The way substitution (splicing) works when parties come and go, an outgoing Finch will not get the report announcing its demise. This makes it even harder to let a Finch know when it's disconnected, so that it can clear the active indication from the conversation log and stuff like that. It has to work this way, though, because by the time the report is issued, the $Poacher link will be broken to the abandoned $telephone party, so the report wouldn't reach the still-active telephone. Modified to splice new poacher in only when owners are the same.
April 24, 1986 2:56:21 pm PST
Thrush
If we record an ongoing call as belonging to the new poacher when the poacher arrives, that's not always an accurate reflection of truth. (The call may have been/probably was to the owner not the poacher). Check whether the owner is the poacher before splicing the conversation over. Always have to splice when a Finch is going away, though.
April 11, 1986 9:42:06 am PST
Feeping audibility and tone length is controlled by specifications in the feep string. Still haven't restored the ability of Finch to feep.
"A\005P\010O\007F9325\002P2936" would (A) allow the user to hear the tones, (P)ause 500 ms. before starting, feep the string 93252936 with 80 ms (O)n intervals and 70 ms of(F) intervals, pausing for 200 ms. between the "5" and the "2".
April 11, 1986 9:43:18 am PST
April 19, 1986 4:16:05 pm PST
Thrush
radio mode is known to LarkInfo, but extended to include the selection of line A or line B. Radio mode is cancelled at the beginning of each call and must be restored.
April 11, 1986 9:43:18 am PST
April 19, 1986 4:15:44 pm PST
Thrush
One of the last-param data types to EnterLarkState turns modes like lineA and lineB on and off. The last-param stuff should be extended to be a list of specs of some kind, including Atom.DottedPair for property-like stuff. Replace current bundled nonsense. Restrict meaningfulness where necessary to one of each type in each request list.
April 11, 1986 9:43:18 am PST
April 19, 1986 4:24:19 pm PST
Thrush
autoAnswer mode is a function of the database only. The only effect on LarkOut is that in autoAnswer mode, the auto-offhook stuff produces a telset state rather than a speakerphone state. I don't believe that any more: the only effect on LarkOut is that if there's also a $TransmitOnly setting for the individual, receive direction is inhibited.
March 25, 1986 9:02:18 pm PST
April 11, 1986 9:42:35 am PST
In Telset mode, speaker click => monitor mode. In monitor mode, hanging up => spKr mode. Draw state table.
States:
$idle: on hook, speaker switch off, no call in progress
$telset: off hook, not monitoring on speaker
$monitor: was $telset, user clicked. Monitoring on speaker
$mONITOR: was $telset, user turned on speaker switch. Monitoring on speaker. Switch on.
$speaker: user clicked (from $idle or from $telset and hung up) or started from Finch
$sPEAKER: user turn speaker sw on (from $idle or from $telset and hung up). Switch on.
March 27, 1986 10:57:22 am PST
April 11, 1986 9:42:36 am PST
It will be simpler if a Click/SpeakerOn decision is made before any action is reported to the client: speaker switch action can be ON, OFF, or CLICK. One could choose to treat ON when ON or OFF when OFF or CLICK when ON as errors, but better to take most harmless course.
February 1, 1986 3:38:01 pm PST
April 19, 1986 2:43:40 pm PST
There are more Loganberry comments in the Important section that DTerry hasn't seen yet. Collect a few and then send them.
January 27, 1986 9:36:10 am PST
April 19, 1986 2:43:54 pm PST
Things to do to upgrade Nuthatch in ways that don't conflict with VoiceRopes:
Allow more than one voice message ID in a header. Play all of them if nothing selected, the selected one if there is a selection. 2
WalnutVoice interface extends FinchSmarts to include the database stuff. Move some of the FinchSmarts noises stuff into WalnutVoice. (?) Maybe do another registry at the WalnutVoice level. More Intervoice. Reorganize to allow access to the voiceFileID database without any reference to Walnut! Necessary for Peanut integration anyhow. Some stuff migrates to VoiceDB? 3
Needs thorough failure analysis, before being promulgated at all. OK to behave simply, but not OK not to catch something. 6
Try it on the real server.
6.5
1. Just try it.
2. Make LoganBerryService.DF.
Contains all the Rpc files I've created.
Lives on CedarChest.
Upgrade Finch.df.
Gets announced to CedarUsers. (No. Not really valuable except internally to Finch right now, because of Export's reliance on Names.)
Change announcement to VoiceProject^, adding whatever else might be interesting.
3. Upgrade WalnutVoice.load.
4. Move the Tunes and TunesRefs databases to 6.0/top and reasonable subdirectories — shared with Morley or something. Change them to use Exports and include them in DirectoryFiles. Further update the Thrush.cm file and all that.
5. Make a new RPCRuntime that knows how to do explicit importing and use LoganBerry as the initial candidate. Make a note (Important) to retrofit everything for Thrush/Finch 7.
6. Get some Alpha-users.
Go on to step 7. Decide whether to release new Finch before or after that.
Copy the essence of the design from the present strange place to somewhere more permanent. Turn it into a message to VoiceProject. 1
Use MBQueue for buttons. (abandoned) 10
January 19, 1986 3:17:18 pm PST
April 19, 1986 2:46:30 pm PST everything is in train.
Must upgrade inline marshalling to do Atoms right. Must also release that for next Cedar bounce or release. Must check with all present users that the modified stuff will work right. Servers in fact will have to change first.
February 21, 1986 10:25:10 am PST
April 19, 1986 2:37:54 pm PST
RPC
RPC changes:
1) Inline Atom marshaling sends NIL as the pName for NIL supplied as an ATOM, and treats converts a NIL pName to a NIL ATOM when unmarshaling. This matches my version of the out of line marshaling.
2) Add an optional host hint argument to RPC importing; allows Grapevine to be circumvented when the caller (thinks it) knows the host number, with Grapevine backup when that turns out to be false. Allows instance field to remain an Rname.
a) Produce Extras interface, with ImportInterfaceFromHost procedure defined.
b) Implement ImportInterfaceFromHost in RPCBinding.
c) Lupine produces calls on new interface, providing similar parameter to clients; default is not to use hostHint. Don't think an option is needed, as long as things are released in the right order.
d) Problem: Means releasing a Lupine that produces code referring to an Extras interface.
e) Work out Mesa-related things with Hal.
February 24, 1986 5:22:17 pm PST
February 26, 1986 5:38:43 pm PST
Atom=NIL is being incorrectly marshaled by the RpcRuntime that I have most recently installed! Wonder what went wrong. Mayhap I didn't fetch my old implementation as part of this latest round!
February 22, 1986 3:25:13 pm PST
February 26, 1986 5:38:46 pm PST
New function in VoiceUtils: NetAddressFromRope. New function in NamesGV: GVHostFromInstance, but can't use it until Growler can be upgraded. OK to include in interface, since it's at the end. For the moment, importers have to simulate it. But see its implementation for guidance.
February 17, 1986 6:08:55 pm PST
February 26, 1986 5:39:07 pm PST
4. Attempt to call poacher's home phone from poachee phone fails ("for some reason"). Narcissism stuff, I think. Narcissism defined as "voice party = voice party".
February 17, 1986 6:08:55 pm PST
February 26, 1986 5:39:38 pm PST
Attempt to call poachee phone from poacher's home phone succeeds (and Finch doesn't record the call!) Crashes, though, after next thing. Narcissism defined as "voice party = voice party".
February 17, 1986 6:08:55 pm PST
February 17, 1986 6:08:58 pm PST
1. Calling from home phone to poachee phone works, rings own tune at poachee, but oesn't do "both" trip (same tune, shifted and so on.)
February 17, 1986 6:08:55 pm PST
February 17, 1986 6:16:57 pm PST
2. Outgoing BD call from poachee phone causes poacher's home phone line to place the call, but Ethernet connection is not made. The connectionSpec was available when trunkSignalling was requested, but not later when TonesDone caused the switch to trunkTalking. The signalling case didn't let connectionSpecs in.
February 17, 1986 6:07:37 pm PST
February 17, 1986 6:07:40 pm PST
Poaching:
Database sets up right for simple poaching.
Off-hook stuff works OK.
Incoming BD call to poacher's line works.
Need to test straight poaching. Set up so that Strowger owns Constellation, then log in as me.
January 20, 1986 7:50:24 am PST, February 16, 1986 11:43:18 am PST
February 17, 1986 6:06:55 pm PST
Showstopper implementation fairly well understood:
Splice poachee in when poacher quits.
Splice poacher in when poacher registers.
Use new ThSmarts.Substitution call, posted to all, to spread the word — updating stateID OK.
Smartses make limited use of party ID's after call is placed, so updating their knowledge is easy. Think through the process of making sure the party that initiates this change gets properly informed.
Problem: if Poacher registers when another poacher is in effect and it's in a conversation, shouldn't redo Poacher stuff, since old workstation will lose the call? Maybe that's OK, since new one will pick it up. See if this can be done with two steps, the first informing the old workstation that it's out of the loop. Check case where Lark registers in during BD call to same person.
Comment on above: only serious problem involves parties that are not yet enabled. Do not connect a $Poaching link to such a party, or dissolve any existing ones.
Unsplice:
When (after) removing a $Poaching link, foreach conversation the former poacher was in, splice the poachee in, then notify all that the poachee is now it. Notification includes the instigator somehow. Splicing the poachee in means copying $Party, $Originator, and convState links, breaking similar links of the old poacher. Finch: if it's us, we're gone and shouldn't try to re-register.
Splice:
Completely symmetric: copy backwards, now concerned about situation poachee was in.
January 5, 1986 11:52:52 pm PST
January 6, 1986 8:43:59 am PST
convID needs to be passed in to FinchSmarts.PlaceCall. Must therefore be obtained one way or another from current selection, and sent on in. Simple matter to determine where that should happen.
January 3, 1986 10:26:05 am PST
Rolodex-calling still not making proper checks (reserved/parsing OK).
December 26, 1985 5:29:41 pm PST
January 3, 1986 10:25:57 am PST
Validity checking for placing calls from Finch is now a travesty. Must deal properly with either (a) the knowledge that there is only one interesting call, and we have a responsibility to help maintain that fact, or (b) dealing with the full multiplicity. Also, need to avoid deselecting a conversation when another that is not to be selected comes in. Different approach to how to specify conversation selection.
December 26, 1985 3:51:47 pm PST
December 26, 1985 5:31:01 pm PST
Called-party field doesn't fill in for outgoing calls from the Telset. Logic is now wrong that was once right. Foo.
December 26, 1985 3:43:28 pm PST
Remember throughout that NIL atoms get marshalled as the atom with the null PrintName. Affects a lot of decisions. That should be fixed! See Hagmann!
December 26, 1985 11:36:20 am PST
January 4, 1986 5:33:55 pm PST
workstationhost in GVMake is done wrong; shouldn't append .lark.
November 26, 1985 4:09:21 pm PST
February 26, 1986 5:40:28 pm PST
Call to self if poaching on somebody else reaches own office. Solution to this has to wait. Would be nice to nip all narcissism in the bud at GetParty time, but so far that's complicated. Wait. (did that, by the way)
December 2, 1985 2:12:13 pm PST
February 26, 1986 5:40:48 pm PST
Holes in the present implementation:
Registration/Deregistration/Multiple services don't work right. Want trunk registration to be more independent. Now is the time to get registration/deregistration to work right.
Local trunk when remote not available: not sure it's implemented, probably doesn't work.
$Poaching not tested.
Not all complete, but other more detailed items supercede this one.
February 2, 1986 11:25:16 am PST
February 26, 1986 5:42:44 pm PST
Explicit export should be eliminated. Explicit import should be accomplished by allowing the import client to specify the machine name/number as a hint. Done, need to negotiate installation.
February 2, 1986 11:25:16 am PST
February 26, 1986 5:43:01 pm PST
Export/Import Loganberry explicitly.
January 31, 1986 8:02:33 am PST
February 26, 1986 5:56:27 pm PST
Loganberry suggestions:
(sent) Should have the option to specify the index files as df comments, so that only the log files are SModel'ed.
(sent) Want to be able to specify a key as the concatenation of a number of fields (specifying the separators? (abandoned for now)
Is key lookup case-sensitive? I'd prefer not.
(sent) Still have some notion there should be a way to get a short Unique ID on a database, representing the most recent version, that lasts not only over an SModel or something else that writes new versions, but also over sessions of the server. Just a 32-bit version of the DB file name. This could be a(n optional) parameter to every call, instead of/as an option to the RefID ones. Means that calls could time out, or yield "temporarily not available", but would never lead to an out of date reference or "no such file" sort of thing. The out-of-service feature isn't too interesting at present, since many of the subsequent actions will in fact result in the referenced DB never coming back into service. The client is going to have to decide, when faced with an out-of-service database, that it's closed forever, and to issue another Open — can't even really figure out when to do it?
(sent) On Open, Log and index file create dates should be checked, and an automatic rebuilding of the index done if any are found to have differed. This could conceivably lead to unnecessary work, but that's OK. I've already been bit by unsynchronized files.
Probably Loganberry should register some commands for opening (i.e., generating an initial entry for), closing, reserving/releasing, rebuilding, and compacting a database. Or the browser should include these functions (opening is trivial); or both.
A browser shouldn't close the database when it's destroyed.
I think an atomic replace is important. If I'm dealing with a remote DB, it's easy to envision communications failing between the delete and the subsequent insert. I can accommodate that, but I'm not sure how reliably!
LB.SetRemoteAccessI should include a comment field that is repeated to the user in the explanation when a DBNotAvailable ec is raised from Loganberry.
February 3, 1986 2:24:14 pm PST
VoiceDBImpl should be willing to re-import LoganBerry; otherwise the automatic recovery code doesn't work.
February 2, 1986 1:18:19 pm PST
February 2, 1986 11:12:15 pm PST
Playback of multi-entry message headers doesn't always work. It's because FinchSmartsImpl.ReportIntervals doesn't work right, and that's because of a bug in ThPartyOpsImpl that puts an unknowable value into the stateID subfield of the unique identifier for the interval. The details are too complicated to report — has to do with the fact that stateMismatch doesn't occur as long as you supply a stateID as large as the last one that affected you — but the actual stateID may jump by more than one when calling SetIntervals and SetIntervals updates all the requests (erroneously, more or less) before posting the events. All fixed in Thrush 7. To get around it in Finch 6, just don't zero the sub-ID value, and compare only on it. Takes 65000 or so requests before it wraps around.
February 2, 1986 11:45:40 am PST
February 2, 1986 1:17:33 pm PST
Catch "no such index" stuff from Retain and Forget at the RecordPlayImpl level, turning them into benign complaints.
February 2, 1986 11:39:51 am PST
February 2, 1986 12:23:55 pm PST
If there's nothing to do during Retain, don't do anything.
February 1, 1986 1:53:05 pm PST
February 1, 1986 2:05:15 pm PST
Change Thrush 7.0 version to leave these values TRUE:
← LarkOutImpl.echoStyleNoFD.buffer1Controlled ← TRUE
← LarkOutImpl.echoStyleNoBD.buffer1Controlled ← TRUE
February 1, 1986 1:53:05 pm PST
February 1, 1986 2:03:55 pm PST
Temp fix in released Thrush: echoStyleNoFD and echoStyleNoBD in LarkOutImpl patched by adding lines to Thrush.cm:
← LarkOutImpl.echoStyleNoFD.buffer1Controlled ← TRUE
← LarkOutImpl.echoStyleNoBD.buffer1Controlled ← TRUE
SModel just that.
January 31, 1986 7:25:05 pm PST
February 1, 1986 1:52:25 pm PST
It is still the case that resetting a Lark does a better job of getting the echo tables right than setting them back the desired way does when returning from Speaker to Telset. This is true both front door and back. I verified this today.
The problem is that when you turn off echo-suppression, by supplying a table that doesn't indicate which channel controls, there will be no more effective calls to SetInGain in LarkAnalog, since it doesn't do anything if there's no controlling channel. This leaves the gain table set at its most recent value, suppressing all further telset conversation. Not sure why switching back and back again doesn't help. The next three entries (back to front, remember) deal with solutions.
January 30, 1986 3:53:03 pm PST
January 31, 1986 10:18:22 am PST
refID isn't unique in refsTo database. include creator and refIDType.
Now rid: entries when type is GVID are like "swinehart.pa/Terry.pa $ ....", where creator name is lowercaseified.
January 27, 1986 7:33:35 pm PST
January 27, 1986 8:48:02 pm PST
Extended voice messaging to allow multiple voice file ID's in a message. Now need to put multiple voice FileID's in the interest entry. VoiceDB.Retain will accept multiple calls with the same GVID and different VoiceFileID's. VoiceDB.Forget is unchanged. VoiceDB.Query now accepts either a single VoiceFileID or a RefID/Type pair; one or the other must be NIL.
December 9, 1985 9:56:37 am PST
January 19, 1986 3:31:46 pm PST, ignored.
Verbatim, from a handwritten note: "Loop in deciding BY? Both smarts?"
November 26, 1985 4:09:21 pm PST
January 19, 1986 3:29:31 pm PST
Throughout, must deal with trunks when front doors die and v/v. Or must we? Work briefly on decoupling them as much as possible, including in LarkOut. No, they should be coupled at this level.
November 26, 1985 4:09:21 pm PST
Bug: LarkSmartsImpl.DeregisterIfRegistered doesn't compute the right host atom. In fact, it needs to try various types out to be sure usages are not changing and screwing things up. As usual, the need for trunk and lark smarts to be in synch causes problems. Think the registration/deregistration/crash scene out again after things work. For now, presume that the types remain the same and that we're not registering multipled services.
November 26, 1985 4:09:21 pm PST
Don't take structures apart until all conversation-ending has been done? No need to delete parties if they can be revived.
November 26, 1985 4:09:21 pm PST
Do better job of idle party registering-deregistering-obtaining-deregistering when done.
November 26, 1985 4:09:21 pm PST
Figure out what party.numEnabled means now. Finch should maybe enable its party instantly? Maybe this should apply only to voice terminal smarts? Examine how used and come to terms with it. With multiple parties involved for one participant, so to speak, numEnabled is probably not a reasonable thing to look at anyhow.
January 18, 1986 6:54:06 pm PST
January 19, 1986 3:16:11 pm PST
Lark deregistration: on reregister, doesn't deal with Trunk (do first!)
On any sort of deregister, doesn't clear $telephone, $trunk, $Extension links (check others)
January 18, 1986 6:40:04 pm PST
January 18, 1986 6:41:24 pm PST
GVOperate 155 sets Lark 155 to Operational; GVOperate 155 Foonly.Lark specifies the instance.
GVDebug 155 sets Lark 155 to Larktest debugging mode; GVDebug 155 Morley.lark specifies the instance.
January 3, 1986 10:28:54 am PST
January 18, 1986 6:22:14 pm PST
Once a trunk party has been used for an outgoing calls, incoming calls look to it like outgoing, they report the last outgoing number, and they feep when you try to answer them. Fix by clearing outgoing field (and name field?) when using a trunk for incoming. No, really fixed by using outgoing value only when trunk is not originator of call.
December 26, 1985 3:49:59 pm PST
January 3, 1986 1:28:43 pm PST
For some reason, NIL atoms are marshalled as atoms with a zero-length print name, unmarshalled without test. That's bogus. Should test NIL and not do MakeAtom on unmarshalling side. I think I'll fix it and release a version of RPCRuntime for me again, rather than trying to deal with all the non-NIL's. This will (eventually?) require a change to Lupine so that those who chose not to call the fixed routines won't get screwn.
Fix: change LupineRuntime to marshal NIL atoms as NIL and to produce NIL as the result on the other side. Inform HThompson, if he does atoms. I've got such an RPCRuntime that I install as Basic.Loadees.
December 12, 1985 11:57:50 am PST
December 12, 1985 4:26:03 pm PST
Extensions handled wrong. Calling by number won't reach poacher as it stands. Once it does, the exotic (Finch but no Lark) stuff will get into a loop. Fix: $Extension[rName]=$number. Have a version of GetPartyFromNumber that will not follow the extension to an active party. Redefine the trunkOK bool to be trunkRequired.
December 11, 1985 3:21:51 pm PST
See Poachers message sent to VoiceProject^ this day to get the latest version of the switching design.
December 11, 1985 3:20:27 pm PST
January 3, 1986 1:28:22 pm PST
When somebody is running Finch but not an Etherphone, or doesn't have an Etherphone, another Etherphone caller should be able to call him or her, notifying the Finch of what's happening (almost -- it will look active while it's ringing) but using the back door. The easiest way is to set things up so that the callee is poaching on the caller's selected outgoing trunk. (Be careful about other calls arriving at that Finch while the first is in progress, but) Maybe the easiest way to do this is to have poaching be set up at GetParty time, computed anew, rather than at Create/Register time. Similarly, visiting, if that is retained as is. I'm going to attempt that. Poaching will be set up as a trunk is reserved for a calling party. You can do it only if the reservation succeeds. It shouldn't be changed if the present poachee is active (to prevent taking a connection away from somebody who already has it.) This sounds dangerous.
December 10, 1985 9:51:52 am PST
December 10, 1985 10:59:09 am PST
On-hook can now happen to an idle conversation, or when a call is ringing in. Ignore it!
December 9, 1985 10:10:35 am PST
December 10, 1985 9:51:45 am PST
both-tunes don't plug in octave thing right for back door call.
November 26, 1985 4:09:21 pm PST
If called-party is running Finch but has no Etherphone, call via back door.
November 26, 1985 4:09:21 pm PST
Consider ways to deal with back door incoming calls while front-door busy. Every new ring now generates a new off-hook. If the callee hangs up, there might be time.
November 26, 1985 4:09:21 pm PST
January 3, 1986 1:29:23 pm PST
Progress report that doesn't encounter voice terminal needs to report to own trunk party, if there is one -- how?
Through poaching link set up at GetParty time.
December 10, 1985 11:00:19 am PST
December 10, 1985 11:00:21 am PST
No busy signal, new dial tone, or any of that.
November 26, 1985 4:09:21 pm PST
Revise connection spec stuff for conferences.
December 8, 1985 3:39:38 pm PST
RingTimeout needs to reschedule timeouts on maybe=>ring. Use InterpRingDetect differently.
December 8, 1985 2:16:57 pm PST
December 8, 1985 3:39:32 pm PST
info.phoneNumber doesn't get set up by anybody in LarkTrunkSmarts. Now get it as a variant of ThParty.DescribeParty. Alert trunk reserved test is bogus.
December 3, 1985 6:09:28 pm PST
December 4, 1985 8:57:19 am PST
Larks register as individuals instead of telephones. TUImpl still doesn't know about trunk parties, smarts, or smartsInfo. Fixed, but DoDescribeParty has a type bug.
Conferencing is not supported at low levels. Code is in such that if 3 or more parties show up at the conversation level, conferences will be built as they go active. If a third joins a first two, the conversation should switch from conference to regular, and vice versa.
Trunks completely unimplemented.
December 2, 1985 12:30:27 pm PST
Use RefID from CardTable.
November 27, 1985 2:37:33 pm PST
December 2, 1985 2:21:50 pm PST
Key table sent multiple times. Algorithms were todally bogus.
December 2, 1985 12:25:56 pm PST
December 2, 1985 12:30:19 pm PST
CheckIdle is now always queued on info.reports. It waits for n seconds and then kills an old conversation. During that time no further reports can be made. It's safe to FORK a process to kill the conversation after the n second wait. That will happen asynchronously with reports about other conversations. Argle.
November 30, 1985 4:43:48 pm PST
November 30, 1985 4:59:25 pm PST
info.haveKeys is bogus. Esp. when we begin alternating among conversations. Needs to be cDesc.keyTable and larkInfo.keyTable, and we need to send one whenever they differ. Also, active isn't working at all right. The test for same-hostness now must be made by comparing send and listen socket id's.
November 29, 1985 1:09:59 pm PST
November 30, 1985 4:59:19 pm PST
When one goes $idle, others may go $idle, too. Or into random other states. One must be willing to accommodate those reports, rather than complaining about impossible transitions. One needn't do anything in particular about them, though. This needs fixing quite soon. Worry only about the reportToAll states. Fix: when in $neverWas state, many transitions by others are no-ops.
November 29, 1985 1:09:57 pm PST
December 2, 1985 12:25:07 pm PST
Ring tune cache tests assume that, on Growler at least, NamesGV.GVGetAttribute is directly bound to the impl, not via RPC. Otherwise, have to do a rope compare for equality, not just a REF compare on the ropes. See LarkSmartsSupImpl.GetringTune. Turns out to work as expected. Also determine why we didn't even try to get a ring tune for Strowger (was a collection of trivial things).
November 27, 1985 2:37:33 pm PST
November 29, 1985 1:03:01 pm PST
EnterLarkState[idle] clears dial tone but doesn't clear the LED -- or it comes back on or something. Doesn't really seem to be going idle. InterpretHookState is switching from sPkr to std, moving tones to handset, just before going idle, in the case of onhook. Possibly could eliminate that transition, saving some time. The real bug is that the [hookswitch, disabled] event is not being interpreted right in the Lark parser. This EnterLarkState in InterpretHookState may be responsible for the blurp when you hang up sometimes that has plagued this system from day one. Also entering reserved=>parsing for no reason, but still shouldn't explain unwillingness to go idle. Main problem was that when conversations went idle, smartsInfo.currentConvID was being zeroed before a test for relevance that protected EnterLarkState from being called at the wrong time, in LarkSmartsSupImpl.NoteNewState. Saving the previous value and using that in the test fixes it. The other problems (spurious state transitions) should be eliminated, though. Recap — This is three problems: InterpretHookState is switching to handset mode when detecting the onhook; this is spurious (and ancient); solution is to do nothing on onhook. Parser is switching to Parsing mode when detecting the onhook; this is spurious, too, and might have an analog in the past; solution is to do nothing in that case. CheckIdle is waiting in-line, since it was originally designed to be called from an MBQueued routine. Solution: change Report to have FinishProc return both the report proc and what to report. Finish proc can return something that just checks idle, instead of full progress report, when it's the initiator.
November 27, 1985 2:33:57 pm PST
November 27, 1985 2:50:29 pm PST
info.currentConvID isn't set up when conversation is initiated from LarkSmarts. ThParty checks for all idle doesn't work when there is no associated posting (need to check at end of posting for all idle and no reports outstanding.)
November 26, 1985 5:58:06 pm PST
November 27, 1985 2:53:17 pm PST
In LarkSmartsImpl, if after creating a cDesc, something goes wrong, remove the cDesc from info.conversations. At least once, the credentials in the new cDesc were bogus (PostConvEvent wasn't doing the right thing about informing the caller.)
November 26, 1985 4:51:53 pm PST
November 26, 1985 4:57:04 pm PST
Niggles: RefAddr doesn't do the right thing about trunk party name (kpt). RefAddr doesn't do the right thing about smartsInfo's or smartsData's. show doesn't make the assignment to its second argument. Registration of function to print GMT's doesn't seem to work or something -- for "0". One way or another, conversationID's have to be readable! (didn't fix it this time.)
November 26, 1985 4:31:13 pm PST
November 26, 1985 5:09:29 pm PST
Bug: Reserved-transition from idle is completely bogus — doesn't call ThParty.CreateConversation. Besides, ThParty.GetCurrentParty doesn't seal up and return the result it has.
November 26, 1985 4:26:30 pm PST
November 26, 1985 4:27:18 pm PST
Bug: Test in verify was wrong for $noSuchParty.
November 26, 1985 4:23:35 pm PST
November 26, 1985 4:31:32 pm PST
Bug: smarts.enablesParty not set when party.enabled set? And vice/versa?
November 26, 1985 4:09:21 pm PST
November 26, 1985 4:15:04 pm PST
Bug: individual[ str.pt ] = strowger.lark instead of individual[ strowger.lark ] = str.pt.
November 26, 1985 4:09:21 pm PST
Must run RefIDImpl, CardTableImpl when running Thrush. See if RefIDImpl includes a copy of CardTableImpl. Probably shouldn't.
November 26, 1985 4:09:21 pm PST
Bug: How to dial version-mismatch: Parameters depends on Thrush.
November 26, 1985 4:09:21 pm PST
Bug: Check out an "Import failed"; use attended. Was making wrong test on whether to import or use interfaceRecord.
November 26, 1985 4:09:21 pm PST
Implement ThParty.GetKeyTable!
November 26, 1985 4:09:21 pm PST
$SmartsForHost[$"173#110#telephone"] = <larkSmarts>. $SmartsForHost connection must be able to distinguish trunk from front door, multiple smarts on the same machine, and the like. Or hair up the code that uses it to enumerate and distinguish.
November 26, 1985 4:09:21 pm PST
Change from tunea, tuneb, tunec to ringtune — simplify gv commands — count on text-file truth. Never need to update GV from caches, take that stuff out or don't use it.
November 26, 1985 4:09:21 pm PST
Find better place for SetupRingTunes stuff. Directly to database each time. tuneb, tunec disappear, as do limits on tune length.
November 26, 1985 4:09:21 pm PST
GVMake must set up both workstationhost and larkhost entries for people.
November 26, 1985 4:09:21 pm PST
Have to rethink whole socket stuff, make sure you understand how it works before finishing up connection stuff.
November 26, 1985 4:09:21 pm PST
ThParty: otherHost field is now a Machine, not CARDINAL.
November 26, 1985 4:09:21 pm PST
ThParty: Compute socket ID and conference host ID at the appropriate times. Supply what is claimed in the otherHost field.
November 26, 1985 4:09:21 pm PST
Make sure text-to-speech bit is still being set in LarkInfoBody.
November 26, 1985 4:09:21 pm PST
Connection can be computed at any time after both parties known. Should also record someplace convenient (in cDesc?) whether the connection involves two machines. Or just keep the connection around somewhere convenient. It should really be in the cDesc rather than in the info, though, since it can change from conv. to conv.
November 26, 1985 4:09:21 pm PST
LarkSmartsInitImpl and TrunkSmartsImpl must record smartsInfo back pointers. LarkOutImpl s/b changed not to accept sInfo argument any more.
November 26, 1985 4:09:21 pm PST
Ring tune gets to LarkOut via nth parameter.
November 26, 1985 4:09:21 pm PST
Subdued ring is just blurp. There can be other ring modes.
November 26, 1985 4:09:21 pm PST
Use MBQueue to distribute Progress, one per smarts! A timeout causes queue to be flushed. This prevents Progress from returning dispositions.
November 26, 1985 4:09:21 pm PST
Retain separate supervisor process if necessary to catch supervisory things? If needed.
November 26, 1985 4:09:21 pm PST
C-Rule: once a conversation is reported idle via Progress, no more ThParty calls may refer to it or to the other parties in the call.
November 26, 1985 4:09:21 pm PST
Deal with ABORTED and UNWIND in MBQueue stuff.
November 26, 1985 4:09:21 pm PST
C: document pulling all disposition stuff.
November 26, 1985 4:09:21 pm PST
Pull party.partyFailed and all that if not needed. Use enabled instead
November 26, 1985 4:09:21 pm PST
C: all the nb's returning from calls. Really need to point others at new ThParty and so on.
November 26, 1985 4:09:21 pm PST
C: document service-name-change business, or whatever you replace it with. Like trunks.
November 26, 1985 4:09:21 pm PST
C:
$AssumedParty => $telephone/$service, $AuthenticatedParty => $individual,
$TrunkParty => $trunk -- in other words, use party type as name link to RName.
November 26, 1985 4:09:21 pm PST
C: $VoiceTerminal => $Smarts, $Manager => $Smarts. No more distinguishing.
November 26, 1985 4:09:21 pm PST
C: $Poachee => $Poaching.
November 26, 1985 4:09:21 pm PST
C: Host names represented as ropes or atoms are always in minimal form "3#333#" unless some other requirement dictates otherwise.
November 26, 1985 4:09:21 pm PST
D: Move ring-enable and all that to the database (White pages, eventually!) Include termination times! Subdued ringing is just a burp again.
November 26, 1985 4:09:21 pm PST
D: Have completely removed ring tune stuff from party level. Change it to use the GV data base directly at the smarts level. But based on RName information from current party.
November 26, 1985 4:09:21 pm PST
C: Interim step: don't do gvupdates: leave .lark entries dirty. Don't change non-lark entries through NamesGV.
November 26, 1985 4:09:21 pm PST
No: GVSetAttribute shouldn't mark dirty when nothing's changed? Maybe it doesn't matter any more.
November 26, 1985 4:09:21 pm PST
Q: partyData.partyFailed zapped?
November 26, 1985 4:09:21 pm PST
Probably **0 version of GetParty doesn't work now.
November 26, 1985 4:09:21 pm PST
Q: Eliminate $Extension link in favor of WP lookup? Nope, there's no index on phone number yet.
November 26, 1985 4:09:21 pm PST
Make sure initialization puts the type field in SmartsBody.
November 26, 1985 4:09:21 pm PST
No: Q: stateMismatch triggers progress report for all stateID's higher than own? May need that.
November 26, 1985 4:09:21 pm PST
C: Do office-of by allowing type=$telephone in GetParty calls.
November 26, 1985 4:09:21 pm PST
Use a separate stateID for each party in a conversation in ThPartyOpsImpl. There won't be stateMismatches due to lack of knowledge of other party's actions, only one's own. Makes them very rare.
November 26, 1985 4:09:21 pm PST
Don't allow transitions from $idle.
November 26, 1985 4:09:21 pm PST
Zap conversation some number of seconds after last party goes idle.
November 26, 1985 4:09:21 pm PST
stateMismatch => try again if trying to go $idle, else no-op?