Niclas Hedhman wrote: > On Thu, Nov 13, 2008 at 5:11 AM, Dan Creswell <[EMAIL PROTECTED]> wrote: >> And this for me has always been the crux of the matter. >> >> What takes Jini forward? > > Indeed! > >> Is it, dumbing it down (no offence intended to anyone) > > Uhhh.... Wrong attitude dude. ;-) > If you agree that "Programming Languages are dumbing down the CPU.", > then I can give you some acknowledgement. But in reality, they are > empowering the programmer to do more with the CPU than ultra-clever > little loops of 60 bytes. Jini should have the ambition to make > distributed computing easier. It already does, but I think it can be a > lot better... > >> 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. > > Yes, in practice this might be true, but most people I know will > consume some documentation before jumping in, and the Security stands > out as extremely central (which is good) and described in utter detail > (which is bad)... IMHO, looking at this isolated from all the other > similar experiences (RMI vs JERI, Transient/Persistent/Activation, > Configuration) the sum is immense. > >> 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. > > Ok. The 3 items that I am willing to back with effort; > > * Production of artifacts that can be consumed by other projects > easily. This includes a Starter Kit for curious people, a Fast Track > for common use-cases, and Development Kit with the all the gory > details. > > * Support for simplified testing of Jini services and clients. > > * Buying beer and food for every River contributor when I visit their > home town/city. > > >> 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. > > True, and I don't think anyone here expect changes to be complete over > night. It is about getting the mind and process going. > >> 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. > > I agree 100% on this point. Single vision is a way to not spread the > resources too thin. > >> 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 disagree. The "Starter Kit" out-of-box experience does not have to > work on all permutations of networking topology and what not. It needs > to work on a laptop/desktop with Windows XP or later, Mac OSX and cool > if it works on a handful of Linuxes as well, with a named JDK (1.4?) > or later installed. I bet that covers "high nineties" of all curious > people... >
I think you misunderstood me - I was saying we need to agree on a minimum standard and base our out of the box work around that. I was not suggesting we support all arrangements, merely agree what we do support, detect it and detect what we don't support and report/configure accordingly.... >> 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? > > It has to be. The alternative is not an option... > > > Cheers > Niclas >
