river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman" <nic...@hedhman.org>
Subject Re: Future of Jini/River
Date Thu, 13 Nov 2008 03:10:43 GMT
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?


> 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

 * 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

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


View raw message