I'd still like to promote a new lookup server that includes my changes to
provide the unmarshalled objects as the result of lookup. This would imply that
marshaling of service objects would be a documented behavior of such a lookup
service. The benefits are delayed code downloading as well as the ability to
pass a services/objects between services without the "lost codebase" problem.
I'd still like to promote a much richer set of APIs for GUI based service UI and
contribute my Jini desktop environment into River as an example of how to use
Jini for distributing desktop applications to users with the dynamic update
capabilities associated with mobile code.
I'd still like to get a password based authentication system into the
distribution by default. It could use a service provider mechanism for getting
to authentication stores. I have a PAM based JNI provider for linux. Certs
work now, but are not always the right answer, and are one of those huge barries
for anyone who just wants to control who can use a service. I think this is the
number one barrier to small service proliferation from new developers. They
create web pages all the time with password authentication easy enough. But
they take Jini as a network service and can't do it easily at all.
I'd still like to make it so that inbound calls run as the remote user's
Subject, not as the local service Subject with access to the remote Principals
as a secondary step.
I'd still like to provide my proxied authorization system to the community.
This system uses an XML spec to generate a proxy delegating implementation of
the service interfaces. It uses a provided backing store for persistence of the
authorization. Authentication is through a service provider mechanism. It
provides a service ui to manage the authorization configuration. This allows
you to plug in authorization support at the service export location. A custom
exporter could even do this for you.
Right now, I pretty much have my own fork of Jini for the lookup support. All
these other things are separate libraries which I use to put together the
applications that I need. I'd like to get back to the point of using the River
codebase and helping with it's evolution (or revolution as the case may be).
The lookup server changes I made are just a simple adaptation to the
implementation of reggie. It does provide the ability to not allow access to
the unmarshalled data through the use of an interface which is optionally on the
Reggie service object.
In my cases, I need to have zero code downloads at startup. The networks are
very high latency. I do have to undergo the HTTP HEAD operation to check for
jars that are out of date in the use of my vhttp: protocol handler. So, one
round trip does happen, per jar file, but only if that jar file is referenced.
Through changes to PreferredClassProvider and ClassLoading, I can designate
classes as never preferred so that their resolution will not result in class
loading. This allows me to designate classes such as Name, ServiceType and
others as never preferred and thus I can take all the discovery results and
render an entire desktop of names and icons without any network traffic.
This type of "detail" and "optimization", for me, is a barrier to entry. People
who don't understand the details, will still find value is such optimizations,
but not really understand how or where the effect them.
Gregg Wonderly
