Message-Id: <9302102253.AA09266@Athena.MIT.EDU>
To: aybee@Athena.MIT.EDU
Cc: jud@ceci.mit.edu
Subject: AM2 memo
Date: Wed, 10 Feb 93 17:57:18 -0500
From: Judson Harward <jud@ceci.mit.edu>

	This is a chance for me to get the first draft of a number of thoughts
off my chest.

I)	Brief minutes of the networking meeting with Tomi

	We discussed publishing the interface of objects.  I asked why publish
it.  Tomi said so that you could check for errors in arguments at the receiver
end.  I said that I understood why that was good in principle, and why when you
rely on compiler techniques like rpcgen + cc its straightforward.  In the AM2
messaging scheme, we are proposing checking the arguments of messages at the
receiver end within a process.  What happens if we do the same over the network?
An argument mismatch is a fatal error, no?  It would be if you were using RPC. 
Does leaving the check to the receiver increase the chance of corruption?  No,
because it will still be caught before the receiver does anything, and the
sender can't have acted on the nonexistent return yet.  Upshot was Tomi will
think about just doing the checking on the receiver side and using a version of
the argument list object for marshalling.

	He was also worried about the sender knowing whether a message is
synchronous or asynchronous.  With the new changes to the ADL, it is now
specified in the ADL.  It will be a syntax error to use an asynchronous
message as part of an rvalue, but I wonder if it should matter otherwise.
Thoughts?

II)	We also discussed error handling, and I made a first pass on an
error module.  I suggest that we have a gereal error object that can deal
with three kinds of errors:

	Fatal) Source of the error detects error and supplies error message.
Error object just logs message and exits.  Example: sysntax error.

	Critical but fixable) Source of error detects it, calls an error
method with string, error method puts up a blocking popup with an OK and Die
buttons.  On OK, return to source for source initiated retry.  On Die, ....
Example: videodisc won't respond (is it on?).

	Warning) Source selects default action and calls error method with
string.  Handler logs the message and returns.  Example: can't find font.

	This extends to network messages fairly straightforwardly.

	Fatal) Sender must die so receiver sends the die message to sender.

	Critical but fixable) Well, in a network context that probably means
you have sent me a message I can't perform because of something wrong on my
system.  Popup goes up on receiver, not sender, but I'm open to suggestions.

	Warning) Log message on both.

	This suggests that the error handlers shoul;d shake hands as soon as
two AM2 processes contact each other, and that they probably want their own
socket pair.

III)	Issues I have been brooding on.

A)	Scope

	The problem is that according to our current definition, if a method is
a scope, then the class members are not visible in the method without an extern
declaration.  I now distinguish two kinds of scopes transparent and opaque.
The identifiers of the closest enclosing scope are visible in a transparent
scope but not in an opaque one.  Class definitions form opaque scopes, and
methods and intance initialization blocks transparent ones.

B)	Minor changes in method return declaration.  I suggest that the
prototype look like

	on selector : [Type1 arg1, [... , Typen argn]] [ returns Rtype ]

rather than

	on selector : [Type1 arg1, [... , Typen argn]] [ return Rtype rval]

It creates another keyword, but I don't see any reason to hgave a dummy variable
for the return value in the prototype.

C)	Overloading methods in ADL classes and redefining members.  I am
thinking of outright forbidding it.  Yes, it is a real restriction on the
object model, but it is one that would save us a lot of heartache, and would
very seldom be missed.

D)	The problem of coordinating constraint processing when there are
multiple inputs to the right hand side.  I propose a third message queue along
with the UI and ADL queue for constraint Set_value messages.  It is
checked after the ADL queue but before the UI queue, and it collapses multiple
messages to the same object so only one update is sent.  Details remain to be
worked out, but it looks as if it may do the job, and ain't too ugly.  Let me
know what you think.

	Hope you're feeling better.  Keep your feet up anyway.

							Jud