
* NinjaClassLoader 'bug':
  If the Registry is able to load a class directly on its CLASSPATH which
  ** should ** be loaded from the 'codebase' specified by the server,
  then when the client asks for the class (say, a stub) it won't get the
  codebase -- hence the client won't be able to load the class. Really should
  have the NinjaObjectOutputStream do a check on the classes it's annotating
  to see if they were *actually* loaded from a specified server code base and
  send the codebase down to the client (rather than assuming that if the
  class doesn't have a classloader then the codebase was ignored).

* Make it possible for one NinjaRemoteObject to export multiple interfaces
  with _different_ RMI_COMM_TYPE semantics

* Current benchmarks: int-arg, int-return local RMI: 1.9 ms (TYA negligible)
                      void, void local RMI: 1.7 ms (1.6 ms w/TYA)

		      Server can scale up to 248 open sockets (kernel issue)
		      Server can scale up to 150 ServerThreads before it 
		        starts to slow down a bit
                      --> Fix by killing old threads/sockets, client stub
		          re-creates socket on usage failure

* One-way best effort RMI for 'void' return value RMI's
  - Use UDP to xmit/rx data (no persistent Socket - one ServerThread?)
  - Throw exception from NinjaRemoteCall if the result stream is requested...
  - BENCHMARK scalability!!

* Seems to be some problem with thread priorities: The new NinjaServerThread
  that gets created for an incoming connection takes highest priority so 
  the 'accept' thread never gets a new connection?

* Registry: Add check access for binding permissions etc.

* Update for JDK 1.2 (once available for Linux)

* Look at the DGC stuff again. Looks like it's used to keep a thread alive
on the server to prevent the object from getting GC'd when a client still
has a stub pointing at it. (Even when the client connections may be broken)
In my case the NinjaServerThread is holding a reference to the object (I 
think!) so this can't cause problems unless that thread were to die for some
reason. Read up on it in the RMI spec.

* Look at consistency - do all client connections see the same state?
  --> Yes. Placing 'synchronized' on the ServiceImpl methods themselves
      locks those methods. Looks like the service implementation itself
      is locked - not the other 'wrapper' objects.
  --> What does 'public synchronized class...' do? Doesn't seem to mean
      anything - confusion in Sun's tools?

* Look at scalability issues - try to really hammer the RMI server from
  many clients at once - does it scale?? 

* Performance improvements: Check out correct location of flush() and use of
DataInput/OutputStream. Look at Sun and Kaffe JIT. 

* Codebase and loading of classes - would really like a client callback 
(catch the exception in the right place??) if the class can't be resolved
in the ObjectInputStream. The Codebase is passed along with the object 
currently which is the location that the server says you can find it - is
this dangerous in any way?? 
