river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jools <jool...@gmail.com>
Subject Re: Future of Jini/River
Date Wed, 12 Nov 2008 23:58:27 GMT
> 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.

Agreed. And this is the fundamental issue with Jini, we do expose some of
the more difficult issues when dealing with networks, but we should be
looking at guiding the user through the mire.
I recall a project starting a while back which would probe your system and
give you some advice in regards to how best to configure jini, not sure
where this is now.....

However, once the hurdles are dealt with, users of the technology become
instant fans.

But the initial curve is a bit steep.

But the benefits are worth the investment.

My team have just deployed a Rio based system, which provides Restful based
services, dynamic load balancing and deployment all using the Rio toolkit.
Getting up to speed with Rio was a breeze for the developers as Rio handled
all the nasty stuff most developers just want to leave to the admin staff,
and the admin staff can tune the rio system for their needs.

So, getting back to the point. Jini is not the issue, IMHO. The how easy we
make it for the user, and how confident they'll be in the end result when
trying to convince management that it'll work.


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