river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Chance" <sgcha...@gmail.com>
Subject Re: Future of Jini/River
Date Mon, 10 Nov 2008 21:14:57 GMT

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


On Mon, Nov 10, 2008 at 3:04 PM, Gregg Wonderly <gregg@wonderly.org> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message