Gregg, Please forgive me for what I'm about to say. While all this is surely an engineering marvel - and perhaps necessary, it has no impact or wow factor to motivate 'outsiders' to download, install and use it.
I don't expect to influence the community to make a sharp rudder change, but one is sorely needed to bring River from real obscurity to something of relevance. Sam On Mon, Nov 10, 2008 at 3:04 PM, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > 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 >
