Issues Monitors are seldom locked during Lark initialization; no well-understood methodology for locks at this time. 1. LarkInImpl.RecordEvent isn't locked, but the routines it calls are. 2. LarkSmartsInitImpl.Register[] isn't locked. Consider building LarkInfo first, then SmartsInfo, then calling on ThParty.Register to build party/smarts objects. Different problems than now with re-registration. Finch 7 doesn't distinguish authenticated callers from not. T-t-S Lark doesn't have a trunk smarts/party. Lark front/back door states are still too intertwined. O2I2 usage is hard to arrange in present system. Major issue by itself. Conference server could handle quintets and up. Dynamic assignment to buffers at the beginnings of talkspurts could handle arbitrary sized conferences without the server. Database model is still feeling like a good idea. (Tradeoff between throwing everything away on error/boot and keeping things: minimal disruption on single-point failure vs. less robust system in face of mysteries.) If we can achieve a system where the data base is considered a better model of reality than the real world (subject to correction when the real world is insistent), this will make a nice paper. Consider a way to poll Larks occasionally. Boot them if they've failed. Inadequate Error coverage. Lark Registration: GV database access could fail if Thrush and NamesGV on different machines. LarkSmarts.Register ignores nb return from RegisterTrunk. Not only that, but RegisterTrunk doesn't do anything useful with nb on failure. Should be pointed out that failure to register a trunk if the Lark side succeeds would be very unusual. If ThParty.Enable fails, EnableSmarts returns FALSE. What does that mean? How would EnableSmarts encounter a lark in the state "failed" or "recovering"? EnableSmarts and CheckHookState might not properly handle a failed RPC call to the Lark (of which two or so are possible CheckHookState calls the Lark directly rather than from LarkOutImpl, a violation). If type of a Lark is changed between one registration and another ($telephone to $service or v/v), LarkSmartsInit.DeregisterIfRegistered will fail. Things to do: Lark init Register: DeregisterIfRegistered path needs exploring. Error handling choices in current system: LarkSmarts.Register: (called when Lark is first booted) Just return (after complaining) if can't establish RPC conversation or import lark interface. Just return (after complaining) (without further attempt to clean up) if can't register with ThParty. Ê‰˜˜˜mJ˜FJ˜.—J˜¥J˜;J˜-J˜€J˜«JšÏb0œ§˜×J˜ÁJ˜HJ˜—˜J˜]J˜óJ˜IJ˜NJ˜ÍJšÏy“˜“J˜—˜ J˜@J˜—˜)˜7J˜]J˜e———…— ì {