river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Future of Jini/River
Date Sat, 15 Nov 2008 09:54:26 GMT
Niclas Hedhman wrote:
> On Thu, Nov 13, 2008 at 5:11 AM, Dan Creswell <dan@dcrdev.demon.co.uk> 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

>> 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

View raw message