Hi Simon,
[This is Cc'd to the Classpath team, to give them an update on the status
of NinjaRMI. Simon's original query is included below.]
Unfortunately I don't have much time to work on NinjaRMI at the moment;
my research has taken me into other directions.
However, this would be a great project for someone to pick up and run
with, since NinjaRMI has almost all of the pieces you need.
The wire format is trivial to get right -- I think I basically use the
same format right now, with the possible exception of a few header bytes;
this is clearly documented in Sun's RMI spec.
The real problem, however, is what to do if you are a client using the
Classpath libraries talking to a server using Sun's libraries. If the
server wants to push an RMI stub to the client, the client must be able
to resolve any classes which that stub requires to operate. I haven't
done the analysis to find out exactly what the standard RMI stubs depend
upon, but I am sure that the NinjaRMI class hierarchy does not exactly
mirror that of java.rmi.* or sun.rmi.*.
So it would be interesting to see what classes are needed to accept a
standard RMI stub from a server using Sun's libraries. I don't think it will
be too hard to get it right, since the NinjaRMI stubs work in almost the
same way. The same goes for the reverse situation, when the client sends
the server an RMI stub. Basically the two sides must agree on certain
classes being available (although they may implement those classes in
different ways).
A more serious concern in terms of compatibility is mirroring the full
structure of java.rmi.* in Classpath. NinjaRMI changes the structure of the
RMI classes somewhat, in order to be more flexible. This is fine, since the
"programmer visible" portions of java.rmi.* are quite small
(i.e. UnicastRemoteObject and RemoteException are pretty much it).
But Classpath strives to implement *all* of the classes in java.rmi.*;
it is my feeling that to do so dictates a particular implementation
strategy for RMI overall, and there is no clear distinction between
"programmer visible" classes and "internal" classes. This is an unfortunate
misfeature of the Sun RMI spec, but grew out of the fact that RMI wasn't
really meant to be reimplemented from scratch by third parties.
I would say that a nice "middle point" for Classpath to be at, for
the short term, is to strive to implement the top-level "programmer visible"
RMI API (which is just a few classes) based on the NinjaRMI implementation.
Later on people can go over it and clean it up to make things more
compliant with java.rmi.* as a whole, but my guess is that nobody will
notice or care as long as UnicastRemoteObject and RemoteException work!
I am happy to re-release NinjaRMI under the GPL if that would help. I would
probably say that the NinjaRMI code can be released under the GPL or
Berkeley's own license.
Although I probably won't have time to actually do this work, I would really
like for someone to contact me with an interest in doing it. I will be more
than happy to help them get started and provide guidance along the way.
It might be a good idea for the Classpath folks to post this message on
their website, next to the note mentioning that I'm working on NinjaRMI.
Thanks much!
Matt Welsh
Simon Britnell <[EMAIL PROTECTED]> writes:
> I read on your NinjaRMI page that this is a goal for integration with
> the classpath project.
> How's this been going?
> What's required to plug the two together?
>
