*start*
00500 00024 US
Date: 12 Oct. 1982 10:12 am PDT (Tuesday)
From: Stewart.PA
Subject: Re: EnqueueReceived
In-reply-to: Birrell's message of 12 Oct. 1982 8:44 am PDT (Tuesday)
To: Birrell
cc: Stewart
Quite right. In my usual grumpy way I wanted to make it work on Saturday and played with the debugger until it did. I didn't know, (nor did I check) that all modules are exported.
-Larry
More of a comment about how reasonable the runtime type stuff is getting than anti-information-hiding.
*start*
01526 00024 US
Date: 12 Oct. 1982 10:38 am PDT (Tuesday)
From: Stewart.PA
Subject: Analog board parts
To: Ornstein
cc: VoiceProject↑
There is an absurdly large collection of disparate resistor values. While many of them are chosen for good reasons, many are not. Those whcih are chosen as digital pullups/downs should be consistant (and probably SIPs rather than discrete.) It won't change the cost, but will simplify assembly.
The analog ICs should all be of the pastic variety where available. This means that there may be additional letters in their names: MC1458P instead of MC1458, etc.
There is no particular reason for some of the disparate capacitor values either. Things like the 6.8, 10, and 22 uF can call be rationalized, subject to voltage rating.
Do there exist SIP style capacitors?
Should a bridge rectifier be used in place of the 4 1N4003s?
Mike has a new switch located for the speaker box.
Connectors and cables for the analog stuff:
4 wire modular cord
8 wire modular cord
4 & 8 wire modular PC connectors
9 pin D shell PC mount for cable to speaker box
9 pin D shell cable
9 pin D shell for speaker box
RCA jack for speaker
short RCA cable for speaker
Mike connector (PC mount)
4 RCA or whatever for Line In/Out on PC board
(& maybe others)
It seems to me that we also need a temporary PC board to occupy the locator space. There are a batch of signals that will be inaccesible without the locator board to carry them accross from the internal connector to the edge of the box.
*start*
01342 00024 US
Date: 13 Oct. 1982 11:10 am PDT (Wednesday)
From: ornstein.PA
Subject: Etherphone parts
To: Stewart
cc: Ornstein, VoiceProject↑, Overton
Reply-To: ornstein
I now am building a comprehensive parts list and will shortly give you a copy
of the current version. It's not complete of course but we're working on it.
1. Can we compress the resistor types more than what we did yesterday?
2. You say we should get plastic IC's for the Analog parts - how about the parts
for the DIGITAL board? Shouldn't those be plastic too where available?
3. Mike says he doesn't know of capacitor SIPS
4. Well - SHOULD a bridge rectifier be used in place of the 4 1N4003s????
5. About the temporary Locator board - I understand, but do you think we need
one for each etherphone or do you just want one or two for lab use?
I'm getting samples of the PCB mount miniature jack/plug combo for the
microphone. It all sounds OK and Mike agrees we can easily rewire the mike.
That eliminates all the garbage about plugging into the spkr. box or whatever.
I haven't yet got the samples of the PC mount RCA phono jacks but they're
apparently readily available. I'm cheacking back to find out what happened to
them.
I should plan on mounting the two 0.1 ufd caps shown on EAP07.sil for the LED
and the switch inside the spkr. box - right?
*start*
00783 00024 US
Date: 13 Oct. 1982 1:10 pm PDT (Wednesday)
From: Stewart.PA
Subject: Re: Etherphone parts
In-reply-to: Your message of 13 Oct. 1982 11:10 am PDT (Wednesday)
To: ornstein
cc: VoiceProject↑
Reply-To: Stewart.PA
1. Can we compress the resistor types more than what we did yesterday?
Yes, I'll work on that as soon as some more software is working.
4. Well - SHOULD a bridge rectifier be used in place of the 4 1N4003s????
A: No.
5. About the temporary Locator board - I understand, but do you think we need
one for each etherphone or do you just want one or two for lab use?
A: Later. No hurry about this one I think.
I should plan on mounting the two 0.1 ufd caps shown on EAP07.sil for the LED
and the switch inside the spkr. box - right?
A: Yes.
*start*
00874 00024 US
Date: 17 Oct. 1982 1:34 pm PDT (Sunday)
From: Stewart.PA
Subject: Prototype speaker box
To: Ornstein
cc: Stewart
That speaker box doesn't work.
1) The cable is wired all wrong. There seems to be some disagreement between you and Mike about how the connecter is numbered.
2) Not all the wires in the box are continuous. For example, the black wire from the switch doesn't show up at any connector pin.
I started to fix it, then decided to work on software instead.
I thought of two additional problems however:
I will need to know which LED terminal is which, since it only lights up when voltage is applied the correct direction.
If I change the speaker amplifier to push-pull, then neither side of the speaker connector should be grounded to the control-box. Instead, the switch black wire should also be grounded to the box.
-Larry
*start*
00306 00024 US
Date: 17 Oct. 1982 11:12 pm PDT (Sunday)
From: Swinehart.PA
Subject: New LarkComm
To: Stewart
cc: Swinehart
Fixes one or two things, maybe. Provides the additional RPCFir calls. Has some
traps in it for the protocol bug we observed (I can't make it happen in my
configuration.)
*start*
00787 00024 US
Date: 18 OCT 1982 0042-PDT
From: STEWART.PA
Subject: Lark power requirements.
To: VoiceProject↑
I've hooked up Meadowlark entirely to the Condor supply and
made some measurements.
The digital board draws 2.4 amps at +5 and about .02A each at
+12 and -12. The analog board draws about 100 mA (I forget exactly)
at +5 and 80 mA each at +12 and -12. The +12 current rises to
about 280 mA at maximum volume.
These results are well within the capabilities of the Condor
supply, so we might as well buy some more of them.
We haven't talked about fusing and power switches for Lark, but my
inclination is to have both a fuse and a power switch. What
do you think? I am always annoyed when I have to crawl under the
desk to pull the plug of something.
-Larry
*start*
00453 00024 US
Date: 18 Oct. 1982 12:50 am PDT (Monday)
From: Swinehart.PA
Subject: Re: Lark power requirements.
In-reply-to: STEWART's message of 18 OCT 1982 0042-PDT
To: STEWART
cc: VoiceProject↑
Reply-To: Swinehart
I don't BELIEEEEVE that Larks are powered by Condor supplies. Far freaking
out! I get this image of little larks fluttering up under a circling condor to
refuel in midair. Let's just hope they don't go extinct on us.
Dan
*start*
02306 00024 US
Date: 18 Oct. 1982 3:46 pm PDT (Monday)
From: Owicki.PA
Subject: Monitor locks
To: Swinehart
cc: voiceProject↑
Reply-To: Owicki
Dan,
After going over the monitor structure I don't think we have any problems for
October (well, not any obvious ones, anyway). I do see some things we will
have to think through carefully in susequent iterations, and I'm recording them
now for future reference. Here's the first part of that -- the deadlock avoidance
structure of the present system.
To review the structure, we have five sets of procedures: LarkSmarts,
ThrushSmarts, ThrushFone, ThrushFoneIn, and ThrushConv (the ThrushConv
procedures are in interface ThrushFoneIn, but are implemented in
ThrushConvImpl).
ThrushSmarts and LarkSmarts both lock Smarts data records. They call
procedures in ThrushFone, and may hold the lock while doing so. ThrushFone
is so structured that the only procedures it calls while smarts data is locked are
in ThrushConv, and these return without requiring any other locks.
ThrushFone locks Fone data records. It calls procedures in ThrushConv and
ThrushFoneIn. The Fone lock is held during calls to ThrushConv. In fact, it is
necessary in some cases to hold the lock while making calls to ThrushConv, so it
is always held. The only calls to procedures in ThrushFoneIn are to DoAlert
and DoAlertResults. These are made without the monitor lock being held; also,
they are not part of procedures called from ThrushSmarts, so no smarts lock is
held during the call.
ThrushFoneIn does not lock any records. (This may need to change). It calls
procedures in ThrushSmarts and ThrushConv.
ThrushConv locks conversation data records. In some cases, it assumes that the
fone data record is locked by its caller. It calls procedures in ThrushFoneIn
without holding the conversation lock.
This structure prevents deadlocks, because there can be no circular calls with
locks being held:
A smarts lock can be held in ThrushSmarts or LarkSmarts during a call to
ThrushFone or (indirectly) to ThrushConv.
A fone lock can be held in ThrushFone during a call to ThrushConv.
A coversation lock cannot be held in ThrushConv during calls to any other
module.
Next message is the potential problems to be considered in November.
Sue
*start*
00329 00024 US
Date: 18 Oct. 1982 5:48 pm PDT (Monday)
From: ornstein.PA
Subject: Re: Lark power requirements.
In-reply-to: STEWART's message of 18 OCT 1982 0042-PDT
To: STEWART
cc: VoiceProject↑
Reply-To: ornstein
Yep - I agree - fuse and pwr. switch. They're actually on one of my dwgs. I'll be
sure Mike remembers.
*start*
00335 00024 US
Date: 18 Oct. 1982 6:55 pm PDT (Monday)
From: Stewart.PA
Subject: Blue phone
To: VoiceProject↑.pa
The blue phone is installed in the analog prototype & works fine. I have assembly instructions made up (on paper) for rewiring the others.
We should order more of them I guess, different colors maybe.
-Larry
*start*
02093 00024 US
Date: 19 Oct. 1982 9:42 am PDT (Tuesday)
From: Owicki.PA
Subject: More on monitor locks
To: Swinehart
cc: VoiceProject↑
Reply-To: Owicki
Dan,
Here are the areas we will have to think about seriously in the next version of
the system. They are all places where we are not now holding locks. The first
two are broad questions about system organization. The last two are pretty minor
changes that could be made now without much effort, if we want to do that.
1. Lark communication. The lark has no monitor, so we need to either be sure
that it will operate correctly given overlapping calls, or else make sure that
Thrush doesn't send it any. We may also find that the current structure of
Thrush allows calls to reach the lark in an order that we don't like.
2. Multiple Fone-Smarts bindings. Once we start to allow those, particularly
when they can change dynamically, we have to either lock the binding database
during the time when we are retrieving and using the bindings (i.e. in almost
every procedure of ThrushFoneIn, and probably most of those in ThrushSmarts)
or else make sure that calls based on out-of-date bindings behave reasonably. I
suspect the latter is the better choice.
3. There are a couple of places in ThrushFoneIn (procedures DoAlert and
DoAlertResults) where the Fone is not locked and probably should be over calls
to ThrushConv. I think these places are actually safe, but I'm not sure. I also
think that the locks can be added without introducing a potential for deadlock,
but want to make sure of that.
4. The Zap procedure you wrote enumerates the Fones in a conversation while
the conversation is unlocked. I don't think this will cause us any problems now,
but I'm not sure what will happen if a Fone is added to the conversation while
this enumeration is going on. We can't just make this an ENTRY procedure,
because that could lead to deadlock. One solution is to prohibit any additions to
a conversation that has weight less than 2, since such a conversation must be in
the process of disappearing anyway.
Sue
*start*
00881 00024 US
Date: 19 Oct. 1982 11:43 am PDT (Tuesday)
From: Swinehart.PA
Subject: New LarkComm; new advice on how to cope
To: Stewart
cc: Swinehart
LarkComm brings code up to date with 3.4 RPC. 3.4 RPC pays attention to what
kind of encryption method you tell it to use; 3.3 and earlier always did
CBCCheck if it did any encryption at all. My code followed Andrew's, but I've
always specified ECB in the StartConversation calls in both languages. What
you should do until everybody is using 3.4 and can reliably change back is to
specify CBCCheck in both your C and Mesa programs.
This probably has nothing to do with the crash that occurs when running
Lark.obj on Meadowlark. Or with double-calls (I'm going to try a silly
experiment on that one soon.) Or with the other ghosts and goblins that are
getting in our way.
Tell Watson to wait just a bit longer.
*start*
00411 00024 US
Date: 19 Oct. 1982 1:24 pm PDT (Tuesday)
From: Swinehart.PA
Subject: Still yet another new LarkComm
To: Stewart
cc: Swinehart
Uses less code to call encryption routines; all retransmission timeouts were ten
times too fast. My test program now uses DISLC, and there's still no sign of the
double-call problem. In fact, there's ample evidence of properly working
ack/ping code. Sigh.
*start*
01635 00024 US
Date: 20 Oct. 1982 2:48 pm PDT (Wednesday)
From: Swinehart.PA
Subject: Boolean thing in 8086 C
To: Duvall
cc: Stewart, Swinehart
Bill,
Here's a source that causes the actual Boolean value to be produced and tested:
/* ------------------------------------------------------------------- */
/* Test.c */
struct ID {
int passivity;
int activity;
int ennui; };
struct Header {
int alias;
struct ID id;
int fraudulentIdentity; };
Test(){
int isConv;
struct Header *hdr;
struct ID id;
if (isConv && (hdr->id.activity == id.activity)) isConv = isConv; };
* ------------------------------------------------------------------- */
Here's the result -- costs 10 or 12 bytes, I guess. Since the RPC code is largely
test after test after test, I expect the costs are at least mildly significant.
* ------------------------------------------------------------------- */
;. . .
; Test(){
←Test:
PUSH BP
MOV BP,SP
; int isConv;
; struct Header *hdr;
; struct ID id;
; if (isConv && (hdr->id.activity == id.activity)) isConv = isConv; };
ADD SP,0FFF6X
; BX ← ←isConv
MOV BX,[BP-2]
OR BX,BX
JZ X2
; BX ← ←hdr
MOV BX,[BP-4]
MOV CX,[BX+4]
; BX ← ←id+2
MOV BX,[BP-8]
CMP CX,BX
JNZ X2
MOV AL,1
JR X3
X2:
XOR AL,AL
X3:
OR AL,AL
JZ X1
; BX ← ←isConv
MOV BX,[BP-2]
; ←isConv ← BX
MOV [BP-2],BX
X1:
MOV SP,BP
POP BP
RET;
; Externals Declared Here
PUBLIC ←Test
C←CODE ENDS
; Number of Bytes of Code = 02EX, (46)
* ------------------------------------------------------------------- */
If you come upon a fix, I can help to get it into the files that we keep on Indigo.
Thanks much,
Dan Swinehart
*start*
00390 00024 US
Date: 20 Oct. 1982 5:12 pm PDT (Wednesday)
From: ornstein.PA
Subject: 150 ns. Rams
To: DBrown
cc: Stewart, ornstein, Overton
The 150 ns. Rams you lent us worked. I believe you can get them back from
Larry anytime you want. Would you please let me know the ordering
information (and rough cost).
Thanks alot for the help; it'll save us considerable money.
Severo
*start*
00348 00024 US
Date: 21 Oct. 1982 7:15 am PDT (Thursday)
From: DBrown.PA
Subject: Re: 150 ns. Rams
In-reply-to: ornstein's message of 20 Oct. 1982 5:12 pm PDT (Wednesday)
To: ornstein
cc: DBrown, Stewart, Overton
For ordering you give clay 64K ram, speed you want and he will find a place to
get them from. The price $8.24 each.
Darrah
*start*
01291 00024 US
Date: 21 Oct. 1982 6:17 pm PDT (Thursday)
From: ornstein.PA
Subject: New Voice Sil Libraries
To: VoiceProject↑
Reply-To: ornstein
I have put the following files onto [Indigo]:
<Voice>Sil>voicelb8.sil
<Voice>Sil>voicelb9.sil
<Voice>Sil>voicelb9Pictures1.sil
<Voice>Sil>voicelb9Pictures2.sil
The file <Voice>Sil>voicelb8.sil has its own picture but voicelb9.sil is too full for
anything but the macros so the pictures are separate.
If you put:
8: voicelb8.sil
9: voicelb9.sil
in the [SIL] section of your user.cm, fetch the first two of the above files, and
run sil/i, you're using the new libraries.
I would hope that we can make these libraries, or extensions of them, be standard
for the Voice project henceforth. As voicelb9.sil is FULL, new macros should be
added to voicelb8.sil and its picture updated accordingly.
These libraries will NOT work for earlier rev's of the drawings as there are
conflicting uses of a couple of the macros in font 8. However they WILL work
for the current EPC (PC version of Digital board) and EAP (analog board) files. I
expect to use them as these boards go through further revs.
I have put the latest version of EPC on <Voice>ETP>EPC-Rev-Ah.dm and the
latest version of EAP on <Voice>ETP>EAP-Rev-Aa.dm.
Severo
*start*
01806 00024 US
Date: 22 Oct. 1982 11:35 am PDT (Friday)
From: Swinehart.PA
Subject: Halloween
To: VoiceProject↑
cc: Swinehart
Reply-To: Swinehart
On October 20 at 11:50PM, L. Stewart and I held the first Thrush-mediated Lark
to Lark conversation. P. T. Zellweger was present and performed the ceremonial
left square bracket rite (i.e., answered the phone.) Early transmissions included:
"Watson, come here, I need [sic] you!"
"Trick or Treat!"
"No shit!"
Skylark: "You can't use the Ethernet for interactive voice."
Meadowlark: "I agree."
(exact order of above lost to history)
There remain some short term problems:
Debugging printout slows control responses, especially on Lark. This has
subsequently been repaired. Connections still seem slow to set up,
but we haven't looked at it yet.
Error recovery on both ends is minimal to nonexistent.
Some of the tones hiccup once in a while.
The touchpad can't be used to place calls by number yet.
Sidetone and silence detection values need adjusting.
Memory allocation problems in Lark remain troublesome.
Nobody every has anything interesting to say in our test conversations.
We also have some longer term, more difficult things to deal with:
Silence is really silent. That's annoying.
Connections may always take too long to set up unless they are essentially
sent in advance, with instructions to the Lark on what should
trigger the start of transmissions. We'll investigate after we see
where the time's going in the current setup.
Some fears were allayed:
The delays are simply not an issue, at least when no gateway is involved.
No packet loss problems were noted (not surprising; 2-4% Ethernet load
for one conversation.)
On to Thanksgiving! If we keep this up, we'll have Christmas 1983 in July.
Dan
*start*
01081 00024 US
Date: 22 Oct. 1982 11:55 am PDT (Friday)
From: Swinehart.PA
Subject: A modest milestone
To: CSL↑, VoiceInterest↑
cc: Swinehart
Reply-To: Swinehart
The CSL voice project achieved a minor but exciting milestone on Wednesday
evening when a telephone server running on a Dorado was able to mediate the
establishment of a voice connection between two Etherphone (Lark) processors.
This included the proper appearance of dial tones, ringing, and so on as the call
setup progressed. The delays associated with packetization do not appear to be at
all significant; overall, the quality of the transmission was very good.
One minor annoyance was the need to supply a person's name instead of his or
her telephone number in order to initiate the call, but this shortcoming will be
rectified in the near future.
There's a lot more to do, of course. Don't expect an expensive telephone to
appear on your desk real soon. In fact, don't expect to see a working system
whenever you drop by for a demonstration. But we feel like we're definitely off
and running.
*start*
00360 00024 US
Date: 22 Oct. 1982 12:54 pm PDT (Friday)
From: ornstein.PA
Subject: Re: Halloween
In-reply-to: Your message of 22 Oct. 1982 11:35 am PDT (Friday)
To: VoiceProject↑
Reply-To: ornstein
Congratulations all around! It's surprising what a psychological boost it is to see
its first quiver. Just wait - the fun is yet to come!
CHEERS,
S.
*start*
00284 00024 US
Date: 22 Oct. 1982 2:03 pm PDT (Friday)
From: Taylor.PA
Subject: Re: A modest milestone
In-reply-to: Your message of 22 Oct. 1982 11:55 am PDT (Friday)
To: Swinehart, Stewart, Ornstein
cc: Taylor
Many thanks for the good news, and congratulations ! ! ! rwt
*start*
00813 00024 US
Date: 23 Oct. 1982 4:36 pm PDT (Saturday)
From: Swinehart.PA
Subject: The REAL bug in the encryption stuff was that
To: Stewart
cc: Swinehart
the string that came in denoting the initiator of the conversation was not having
its length swabbed and was occupying around 1500 words. In my program that
was OK. That's how close to the edge we are in Lark.obj!
[indigo]<voice>top>larkcomm.df (I got your changes first).
I haven't tested it yet, but it's gotta work. Working on error recovery -- first
version will let one boot one's Lark and reregister manually, after a Call timeout
or whatever. Probably will support reregistration at any time, assuming the Lark
is in idle mode. The full reregistration to follow somewhat later, probably after
we plan the Thanksgiving system.
Dan
*start*
00309 00024 US
Date: 25 Oct. 1982 3:34 pm PDT (Monday)
From: ornstein.PA
Subject: Voice Project Meeting
To: VoiceProject↑
Reply-To: ornstein
At our last meeting we agreed to meet on Tues. Oct 26 (that's tomorrow) to see
where we stand. Let's gather in the CSL alcove at 10:30 AM.
Cheers,
Severo
*start*
00558 00024 US
Date: 25 Oct. 1982 6:11 pm PDT (Monday)
From: ornstein.PA
Subject: Power Reset
To: Stewart
cc: ornstein
L,
In thinking about it further I think perhaps the picture you drew on Mike's
whiteboard is incorrect. Specifically, I think we want two SET inputs rather than
two RESET inputs. Either the relaxed state of the button or PowerReset' would set
the flop - so that the 1 sec timer can kick the 1 ms. resetter if it needs to.
PwrReset does its own reset by ORing into res'. Looks like we don't need any
inverter. Am I wrong??
S.
*start*
00409 00024 US
Date: 26 Oct. 1982 5:38 pm PDT (Tuesday)
From: Swinehart.PA
Subject: FYI
To: Taylor, VoiceProject↑
Reply-To: Swinehart
---------------------------
Date: 26 Oct. 1982 2:49 pm PDT (Tuesday)
From: Pake.PA
Subject: A modest milestone
To: Swinehart
cc: Spinrad, Pake
Dan,
Congratulations on the "modest milestone".
George
------------------------------------------------------------
*start*
00973 00024 US
Date: 26 Oct. 1982 5:45 pm PDT (Tuesday)
From: Swinehart.PA
Subject: GV RPC Binding Extensions
To: Birrell
cc: Stewart, Swinehart
You now have a customer for a service that would bind via Grapevine by type
only (instance 0 in bind request, I guess.)
Preferably, it would try the candidates in order of lowest hop count from the
requesting site or something equivalent.
What I actually need is a function that will return me the instance data (both
instance RName and a fully specified instance string (e.g., "3#152#36#) for the
specified type, in order of preferred binding, so that I can spoon-feed the
information to the birds (Larks, that is.)
You will doubtless have an improved version of all this to suggest instead of
precisely what I'm asking for here. We will not have any trouble getting along
with what exists now, in the interim (I'll just look directly at the connect
information associated with specific instances.)
Thanks,
Dan
*start*
03066 00024 US
Date: 27 Oct. 1982 10:09 pm PDT (Wednesday)
From: Swinehart.PA
Subject: New LarkComm.df, changes to make
To: Stewart
cc: Swinehart
Incorporates all your changes of yesterday, including LarkBase. I am about to
see if my changes and yours fit together OK.
Changes:
1. Broadcast binding is now entirely internal to the binding system, except that
you must call AgentInitialize() before importing your first interface. This was
supposed to be automatic, but I overflowed all reasonable sized signal vectors by
calling ImportInterface recursively, so . . .
AgentInitialize presently returns false if no "Agent" can be found, true
otherwise; more information about failure can be obtained if you think you
know what you could do with it.
2. You must now include an instance field in your interface names. The
instance field can be of the form:
"Pauling.Lark" -- a valid individual in the Lark registry to which
you export your typed interface;
"CoralSea" -- a valid name lookup server name;
"3#30#" or "3#30#36# -- a valid net/host number.
In other words, the full RPC binding generality is now supported. All the hair
is handled on the Cedar side! I'll support binding by (type only) when and if
Andrew ever does. The "Scientist.Lark" form is recommended. Available
scientists can be determined by listing the members of the group
Individuals.Lark.
Thrush exports [type: "LarkSmarts.Lark", instance: "Morley.Lark"].
The Agent package exports [type: "Agent.Lark", instance: "Michaelson.Lark"].
You can use [type: "LarkSmarts.Lark", instance: "Einstein.Lark"] if you want to.
(By the way, if Grapevine pays attention to version range stuff, we could use
that instead of different type or instance names to keep our Cedar
implementations separate. I'll check it.)
3. You must include the file RPCAgent.rel in your Lark-side load file. RPCAgent
provides clean interfaces (via Fir) to the two procedures in the Agent interface
that Lark will now use broadcast binding to locate: Authenticate and
InstanceForInterface. You should never have to call either of these procedures
directly. You may have to clean them up when it's time to remove Alloc.
4. On the Cedar side, there now exists [indigo]<voice>top>agent.df, which
includes AgentPkg.bcd and AgentPkg.config. The bcd is not code-bound, so you
need all the bcd's that it includes. AgentPkg must be explicitly started, say right
after NamesImpl, in your configuration. It includes the broadcast binding
listener, the Authenticator, and the InstanceForInterface provider. I may be able
to move Identify to this interface someday, too, but it awaits some consultation
with Andrew. You should remove direct references to the broadcast binder and
the Authenticator from your configurations.
5. Please inherit [Ivy]<swinehart>thrush>Lark.mesa (changed data type of
Event.) 'Twould be nice if this file and LarkSmarts could show up in a .df file
somewhere soon. Also, these files can go back into [indigo]<voice>thrush>... as
long as you own the .df file, right?
Dan
*start*
00470 00024 US
Date: 28 Oct. 1982 3:59 pm PDT (Thursday)
From: Stewart.PA
Subject: LarkRPC.df
To: Swinehart
cc: , Stewart
I could not find a Lark.bcd that corresponded to /ivy/swinehart/thrush/lark.mesa, so I have recompiled everything and retranslated the interfaces. Retrieve /Indigo/voice/top/larkrpc.df
AgentPkg.config doesn't exist, nor does AgentPkg
ThrushNet.bcd has wrong version and there is no right version
Do you know about VerifyDF?
-Larry
*start*
00817 00024 US
Date: 28 Oct. 1982 5:35 pm PDT (Thursday)
From: Swinehart.PA
Subject: Some progress
To: Stewart
cc: Swinehart
[Indigo]<Voice>Top>Agent.df is now pretty good, I think. AgentPkg.bcd now
includes NamesImpl and exports Names. Remove NamesImpl from your configs.
I'm going to be moving more of the ThrushNet stuff into there over time, since it
seems generally useful. None of the files in AgenPkg depends on any of the
Lark or Thrush files. The Imports are not specific about dates, but they do have
complete path names.
[Ivy]<Swinehart>Top>LarkRPC.df has a Lark and LarkSmarts that no longer
depend on Thrush. I put them there so you could decide when to incorporate
them. I don't think you'll find any noticeable differences, except the version
stamps.
My system works OK with these.