And this for me has always been the crux of the matter. What takes Jini forward?
Is it, dumbing it down (no offence intended to anyone), is it to fix some bugs, is it to add some new features, is it to have some kind of target problemspace that is smaller than all and sundry? All the code in the world is useless without tackling this core question which comes down to agreeing a vision/direction. As an aside, I've often thought that the real "power" of Jini is the underlying design philosophy rather than the code, certainly I've applied it elsewhere successfully without needing dynamic code downloading or security or even Java. Some random thoughts: I keep hearing how the security model get's in the way but to the best of my knowledge, at least in Jini 2.x it's basically optional. The only thing you require is to install a SecurityManager and have a very "loose" policy file installed which is all about enabling code downloading rather than catering for security. Jini, because of it's design philosophy is quite different from most other systems. It looks a little like OSGi and they are somewhat compatible, probably complementary. Inevitably this brings tension when trying to make Jini fit with other approaches. It can be done, but there's a compromise, I reckon it's about time we explicitly discussed what compromises might be possible and what the penalties are. Prioritise: there's always way more to do than there is resource and this is particularly true for Jini. Pick three and focus on those, and if you suggest a target be prepared to back it with some effort of your own. It's tempting to look at other successful projects and try and copy all that one sees they've done whilst forgetting that they grew and achieved all of this over a period of time, it didn't all happen overnight. I would argue that even this: "Let's make the code easy to get, easy to build, easy to use. Let's post nightly builds. Let's add something to the roadmap (like maybe a release schedule? And then plan on regular releases...). Let's ask each of the service container providers (Rio, Seven, etc.) and the community what their top 3 feature requests are and find the low-hanging fruit (InputStreams!)." ....is too much to start with. Three things, only three things, don't get ambitious, crawl, then walk, then run. Some have argued against prioritisation and singular vision in favour of diversity believing it attracts a large community. I beg to differ, I believe diversity comes as the result of attracting a large community because you've scratched a popular itch. The out-of-the box experience: IMHO, the real trouble is that Jini is a network technology and networks just aren't nice, a single machine can have a myriad of network interfaces, some of them with dynamic IP addresses, some of them registered in DNS, some of them supporting multicast etc. To address this problem requires agreeing on what a minimally acceptable environment might be, having a means to determine whether any given machine meets the necessary requirements and where it doesn't generate useful debugging information to assist in a fix. It also means deciding on what should be possible out of the box, chances are the more ambitious one is, the fewer machines there will be that satisfy the environmental needs by default. I'll finish by saying that I'm pleased to see this debate. However, I've seen it a number of times before and it's ultimately yielded no advancement on the surface because there's been no will to compromise or form consensus. Will it be any different this time? Cheers, Dan. Sam Chance wrote: > 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 >> >
