Jools wrote:
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.
This is one of the things that RIO and other Jini projects have done, over time.
They've derived the foundation of Jini into more useful toolsets focused on
solving some types of problems easier.
Over the years, there has been friction about pulling any of the "simplifying"
bits back into the starter kit. Part of this was, of course because Sun owned
the code and practically didn't have the means and mechanisms to take large
contributes and integrate them I'd guess (licensing and work load mostly perhaps).
Now that we have an open source project, the doors seem open to me.
Gregg Wonderly
