The only concern I have is that the Client and the Manager (i.e.
the client and server) portions using the AltRMI transport will
be largely duplicated code between RMI implementations, SOAP
implementations, SNMP implementations, etc.
My thoughts originally had been to create various connectors within the IM project and then have them all be conditionally built the same way we do with optional classes in the Logkit project. Keeping them all in the IM project is really the only home for them that makes any sense in my opinion.
This should not affect the dependency list of projects that require the IM any more than the optional dependencies of LogKit do
I think there has been confusion because the ECM and Fortress have both been including Altrmi as if they were required.
The important thing -- if you want to abstract out the transport is to seprate out the AltRMI specific portions:
On Manager, it is two classes--all in their own package.
On Client, I would have to check, but I estimate that it is
very similar.
Actually only 1 class. The other is deprecated and has been for quite a while. Most likely it could be deleted. InstrumentManagerAltrmiConnector.java is the only one that is needed.
Leif did a good job of separating out the transport--at least
on the server side/manager side.
The client side is not quite so clean. I was not too worried about it as it is
a stand alone application. But as it sounds like there is a desire to make
it work with other platforms, I am going to need to go in and clean that part
of it up. Most of the "sloppy" code is in the Menu code. And that is actually
not being used at the moment. Free time has unfortunately been a rarity
the last few months. (Apologies for the lack of progress documentation
wise etc.) So I don't want to promise to get it done right away. It is on my
list though...
Cheers, Leif
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
