Received: from ATHENA-AS-WELL.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA18072; Wed, 20 Jan 93 19:44:38 EST
Received: from CECI005.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA04469; Wed, 20 Jan 93 19:44:35 EST
From: aybee@Athena.MIT.EDU
Received: by ceci005.MIT.EDU (5.61/4.7) id AA04513; Wed, 20 Jan 93 19:44:32 -0500
Message-Id: <9301210044.AA04513@ceci005.MIT.EDU>
To: htomi@ceci.MIT.EDU
Cc: jud@Athena.MIT.EDU, aybee@Athena.MIT.EDU
Subject: Networking Chapter
Date: Wed, 20 Jan 93 19:44:30 EST



:)   :)   :)   :)    :)    :)    i like it!


i have a couple of suggestions and comments too.

i think that some examples of each of the interactions might help.  for instance, one application
might provide a line-oriented version of unix "talk" to demonstrate the "lifecycle" of a network
application, as well as to demonstrate a stream-oriented communication.  perhaps another, application,
such as a renderer might be used to demonstrate how more structured data could be sent with a
packet-model. in each example, you could make it clear which services would be used.  if done with
examples, the chapter might start out presenting the applications from the users perspective then show
what is required of the network interface, then show how the network DIX will meet those needs.

i think that you might want to rename the methods to have longer, more descriptive names. i think that
would be consistent with the naming guidelines and would make the interface easier to use.  for
instance, RegPktSender() would become RegisterPacketSender().  in fact, since these functions will be
C++ methods, you gould just call it Register() without fear of namespace collisions.  additionally you
might want to change the Create and Destroy methods to be the standard C++ constructors and
destructors.

im a little confused by your phrase "without connection" which appears in the descriptions of
Register functions as well as some SendMessage functions among others.  what does it mean?  your
diagrams in the last few pages are very cool, but may need a bit of text to explain them; the examples
might help with explaining them.

an explanation of what you mean by the word "object" might be helpful too --- C++ objects? or
interpretted objects? or???

now, for questions that i thought of as an eventual user of libNW:
can i register for callbacks or must i poll my network objects?  (callbacks would be more friendly :) )
what happens if my calls fail? can i get a notification so i can decide how to handle them? or do you
    	kill me?
can i change my NWobjects from blocking to non-blocking after they have been created? can i change
	their timeouts?
don't the PingRequest functions need timeouts?
what if i have 2 applications with the same name running on the same machine? who straightens it out?
     	(i imagine that the name service does, but you haven't discussed it anywhere)
if i run my application which uses NWobjects and there are no name servers running, what happens?
what base types do you support? integers, reals, strings, etc?
what provisions might there be for extending this set?  can i register translators with NWobjects
	which will be called when a certain type of data arrives?  for instance, can i define a
	MyFavorite packet type and register it with you, then give you a function to call when it
	arrives?   (the function might convert the packet to a new format, suitable for executing the
	normal callback on)....i guess, im saying there are two types of callbacks i might want to have
	called when data arrives --- one to translate the type to a more friendly format (to extend the
	set of base types) and one per type to handle the incoming message (after translation)

ummm...that's it for now :)


ab



//////////////////////////////////////////////////////////////////////////////////////////////////////
///   these comments have been brought to you for your pleasure                                    ///
///   as always, you may choose whether or not to use them                                         ///
///   NOTE: these comments come with no guarantee of usefulness, stated or implied                 ///
//////////////////////////////////////////////////////////////////////////////////////////////////////
