Peter Firmstone wrote:
Brian Murphy wrote:
On Fri, Mar 19, 2010 at 7:21 PM, Peter Firmstone <[email protected]>
wrote:
The old jar's are easily removed, but what about obsolete / duplicate
interfaces, any suggestions?
I'm not aware of any duplicate interfaces. Could you be more
specific?
I don't have any specifics in mind, just posing the question. I was
hoping there might be a way to reduce the conceptual codebase size a
developer has to get over to participate in River development.
Actually I'll correct myself here, it isn't the codebase size per say,
it's determining each part and it's purpose, I guess what's really
needed is a good update of our doc's, for the basics of utilising Jini
and the current River implementation, then we could have an advanced
addendum where implementation details and platform issues or corner
cases are discussed, details which are generally only documented on user
list archives and research articles. I did make some recent changes
attempting to dispel some confusion over what constituted the Jini Spec
and the River Implementation. See
http://incubator.apache.org/river/doc/ for our current docs, perhaps we
should create a Jini Architecture Specification Version 2.0? Copy 1.0,
remove all references to using RMI and document the new methods.
Sim & Gregg had a recent discussion about utilising a Static Factory to
help beginners grasp the power and purpose of Jini / River, perhaps
someone has an implementation they might like to contribute?
I believe there were some deprecated items that were scheduled
for removal after the appropriate number of releases had occurred.
Don't know what interfaces would be considered obsolete though;
such a designation might be more about opinion than functionality
or utility.
There have been some comments in past threads about the
value of services like the lookup discovery service and the
lease renewal service; both of which have little usage as far
as I know. Some have even questioned the usefulness of the
event mailbox service, but for what it's worth, I can tell you that
I know of projects/companies that do use that service. So I
don't know where the line should be drawn, or what criteria
should be applied when deciding when something should be
removed.
Do we need to continue supporting rmic stubs? Should we remove
facilities
for RMI communication other than those utilised through JERI?
Are you talking about just removing the generation of the stubs
in the build scripts, or are you talking about the use of JRMP
for example?
I'm not against the use of the JRMP protocol, provided that client and
the Service
implementation don't depend on it, so the Service and client can use
other transport
protocols also.
Exporter exp = new JrmpExporter();
Provided only Exporter methods are used, it can be replaced by any
other Exporter
implementation.
However I believe we still support (discouraged) applications
extending UnicastRemoteObject which implicitly exports a proxy and
require the generation rmic proxy stubs. Having two distinctly
different mechanisms for Remote proxy object creation for Services
causes confusion. At a minimum we need to change our docs to reflect
that.
Seeing that a Service is designed to be an abstraction where service
implementations can be exchanged, it would be wrong to tie a client to
an implementation detail of the Service, which is what extending
UnicastRemoteObject does.
The interface net.jini.core.lookup.ServiceRegistrar has the following
method:
EventRegistration notify(ServiceTemplate tmpl, int transitions,
RemoteEventListener listener, MarshalledObject handback, long
leaseDuration);
Where the MarshalledObject is an instance of java.rmi.MarshalledObject.
Jini has it's own later version of
net.jini.io.MarshalledInstance
net.jini.io.MarshalledObject
Where the latter is a convenience class for converting
java.rmi.MarshalledObject.
This is a little off topic; I've been looking into what's required to
support Java cdc, namely a minimum of Personal Basis Profile 1.1.2 (a
subset of J2SE 1.4.2) and while it supports java.rmi.Remote and all
the exceptions, it doesn't support the server component of rmi and it
lacks java.rmi.MarshalledObject.
There are a significant number of devices: Amazon Kindle, Blue Ray
Players, Set top boxes, extending this profile.
Unfortunately interfaces cannot be changed, however there is something
that can be done:
A super interface without the offending method inserted into the
inheritance hierarchy. However what is actually required to support
cdc is still under investigation.
I'm not sure about the usefulness of manually generating
the stubs.
Are these stubs generated for Clients and Services utilising
JrmpExporter?
I had a search through the source code I can't see any real dependency
on using UnicastRemoteObject?
But if you're talking about removing classes like
JrmpExporter and IiopExporter, I'd be very much against that.
No, Exporters are part of Jini 2.
Brian
Best Regards & thanks for the reply,
Peter.
