Message-Id: <9210121621.AA01703@Athena.MIT.EDU>
To: htomi@ceci.mit.edu, jud@ceci.mit.edu, pbailey@ceci.mit.edu,
        mau@ceci.mit.edu
Cc: aybee@ceci.mit.edu
Subject: networking
Date: Mon, 12 Oct 92 12:23:55 -0400
From: Adam Feder <aybee@ceci.mit.edu>


i imagine that you talked about most of this so i will be brief
things i think ought to be required of our networking utilities:

1) ability to start and talk both directions to another process on the same
machine (pipes)

2) ability to talk to random processes on other machines in a stream (sockets)

3) ability to connect several programs using our package together simply
	possibly with a "hub" that they all know about and that distributes
	the messagess

4) we should provide objects which encapsulate 1,2, and 3, allowing
	both blocking and non-blocking usess

5) a high-level interface inside of ADL....if you know the full name ("handle"
	or "location") of an object on another machine or within another muse
	process on your own machine, you should be able to send it a message
	of any type...just as if it were within your own muse process.

6) we may need some simple ability to get at the following things:
	the time (system time)
	the machine name
	the process id

7) we will need some way to be sure that object "locations" are unique
	it would be nice if sending a msg to an object elsewhere automatically
	connected to that machine so that the programmer didnt have to worry
	about it

	maybe we could use a setup like that of zephyr, have one process
	running per machine whose job it is to distribute mail between
	processes and to other machines, and let muse processes tell that
	process...here i am, and these are the kinds of msgs i will accept


well, that isn't a complete list...neglected to talk about how one shares that
actual media across machines....but i think 1 - 7 will keep us pretty busy

8) we should be able to transmit ximages across machines (like a xwd)

9) should provide the ability to export your mouse's location relative to your
	muse windows and allow another muse process to import it as another
	mouse-like icon.....this should be provided at a low level, because
	the cost of handling those events in ADL and trying to make all the
	decisions about how to draw the icon cost a lot in overhead

10) going along with the timiing issues above, start and stop messages to
	media should be labelled with a time relative to last command or
	by explicit frame numbers to keep things synchronized better across
	the network

11) maybe by analogy with 9 and to do 10, we could provide the ability to
	have not just a video-player but a video-player that just shadows
	another one....so my videoplayer would tell your videoplayer, let me
	know what happens to you so that i can mimic you
	
	maybe it would be enough to just set the "shadowed" videoplayer's
	state to be the one the "real" videoplayer is using...then we need to
	be sure that switching from one having one state controlling an object
	to having another do so is a "cheap" operation to allow for multimedia
	electronic meetings

12) hate to be paranoid but we will need some way to limit the messages and
	who is allowed to listen to what....


i gotta go....
lemme know what you think....

ab