Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 SRS0=Y4e0PN=7N=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.100 as permitted sender)
Message-Id: <D5532BD6-BD83-43C9-B626-FB8C68B2D0D8@wonderly.org>
From: Gregg Wonderly <gregg@wonderly.org>
To: river-dev@incubator.apache.org
In-Reply-To: <964EAC824495234A86F3C47DA8BD8AAD1775D4@sucden-exch.sucden.co.uk>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.4)
Subject: Re: Board Report is due...
Date: Sat, 14 Mar 2009 06:34:17 -0500
References: <caf30e2a0903050016o2e29c6caldcab94566d0c76cb@mail.gmail.com>
 <510143ac0903120535w3ed7fb0ah7db2175463b07817@mail.gmail.com>
 <49B9C629.706@zeus.net.au>
 <caf30e2a0903122006v46b4eec4y923483ab5db77a74@mail.gmail.com>
 <b23c74270903122137h2345961cre402c3c7c4c85588@mail.gmail.com>
 <964EAC824495234A86F3C47DA8BD8AAD1775D4@sucden-exch.sucden.co.uk>
Sender: Gregg Wonderly <gregg@wonderly.org>


On Mar 13, 2009, at 5:41 AM, Tom Hobbs wrote:

>> Perhaps it is time to restart the Jini/River project.
>
> Although that sounds sort of tempting, it didn't work for Netscape  
> and I think such an approach should be avoided.

What I think is interesting is the continued conversation about the  
code.  I am really troubled by this, because, I personally have no  
problems looking through the code and making sense of it.  I don't  
think that the code has problems as much as the developers' visible  
APIs are not "like everyone elses way of doing things."

Clearly there are several large bits of code, built on top of Jini,  
which provide a completely different programming experience/APIs as  
their visible API than the core Jini APIs.  Jini APIs are, on purpose,  
low level APIs designed for putting together larger functionalities  
built around the concepts of secure, mobile Java code in concert with  
the core features which Jini provides, namely lookup, distributed 2PC  
transactions, distributed leasing and remote eventing.

Things like the ConfigurationFile implementation of the Configuration  
interface, remote eventing, ServiceDiscoveryManager,  
LeaseRenewalManager and others, are things built on top of the core  
Jini functions to provide more convenient access to these functions  
for the developer.

Others things can be done on top of the core.  The fact that so many  
others have done this speaks clearly, for me  to the separation points  
that the current River/Jini APIs provide. Jini should really be viewed  
as a platform, not as a "solution" or "service".

We clearly can take a lot of different convenience functions and  
useful extensions that have gelled into many of these large Jini  
projects and push them back into the River project as recommended ways  
to do those things.

We can also just sit around and say that rewriting it or making  
something different or forking would solve all our problems.  I'm not  
convinced that those choices do anything except further fragment the  
concepts into even more ways of doing similar things with no  
interworking standards.

Gregg Wonderly