Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=ctNCOn=4T=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.107 as permitted sender)
Message-ID: <49456087.4070801@wonderly.org>
Date: Sun, 14 Dec 2008 13:37:43 -0600
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Split JavaSpaces and JINI
References: <964EAC824495234A86F3C47DA8BD8AAD17750A@sucden-exch.sucden.co.uk>
	 <caf30e2a0812101858t1fba4351q907c0c5d5a3c4f5d@mail.gmail.com>
	 <9b694b200812110126t2e14f5cg5d4f46607674111d@mail.gmail.com>
	 <4aa658780812110136v10bd3a77v306114a391c39c4d@mail.gmail.com>
	 <97949386-53E7-48F1-8994-3867C55B3149@topiatechnology.com>
	 <1229003703.5106.4.camel@cameron>
	 <0D2211B8-9A22-41BB-AE80-25FC716EAAE7@topiatechnology.com>
	 <4942A7A8.8030801@wonderly.org>
	 <DB4A7E0E-F9B4-4BAA-9BD3-CB461E06B0DB@topiatechnology.com>
	 <49454C81.10508@wonderly.org>
 <570acb770812141043n4c7c9498ledb7c8a366ad97d3@mail.gmail.com>
In-Reply-To: <570acb770812141043n4c7c9498ledb7c8a366ad97d3@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

William Surowiec wrote:
> I can understand the desire to maintain backwards compatibility. But I side
> with the group pointing out adoption has been lower than one might expect
> for such an interesting and useful resource. I do not attribute the reson to
> any of the negative adjectives offered as a description of programmers. I am
> sure it is true for some but not as many as it would take to explain the low
> adoption. I believe - without being able to prove it - the reason is more
> likely the api we have does not address the needs (time to learn is one) of
> the adoptees this technology warrants. (Tulach makes a point regarding
> java's mail api being optimized, but not for users just interested in
> reading and sending mail.)

And I think this is a great point to debate.  I don't think focusing on Entry is 
going to solve any problems compared to what it will create, personally.

For those that don't know, I am not a committer for River.  What I say is my 
opinion and my perspective.  If you want to work on issues that interest you, in 
the River project, I heartily encourage you to do so!

My debate about Entry and the general architecture of Jini is that all of the 
existing code is a foundation which several higher level frameworks have used to 
put forth a face which targets a particular set of use cases.  I believe that 
there are areas in the core of Jini that still need attention (such as the 
ability to look at services without unmarshalling them from downloaded code 
(unmarshalling from well known, local code is something that is not without risk 
either, as was pointed out in Michal Kleczek's recent response to my "Service 
lookup without unmarshalling - details" posting.

Someone can open an issue to "pull Entry out of net.jini.core.entry and put it 
into net.jini.space."  But, someone has to figure out how to do this and a vote 
has to occur to make it happen.  If the committers vote no, then that's what 
happens right?

Gregg Wonderly