river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Split JavaSpaces and JINI
Date Sun, 14 Dec 2008 19:56:35 GMT
----- Original Message ----

> From: Gregg Wonderly <gregg@wonderly.org>
> To: river-dev@incubator.apache.org
> Sent: Sunday, December 14, 2008 2:37:43 PM
> Subject: Re: Split JavaSpaces and JINI
> 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.

Apparently I need to update my spam rules. His message didn't go to my apache folder, but
straight to spam, and I didn't find it until you wrote this :-S Reading now.

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

Sure. I would argue that makes the system less cohesive at that point though because it makes
it an uncommon interface at that point and actually means no spaces no jini which I really
don't think makes sense. I would much rather see a set of sub projects in the whole with entry,
transaction, lease, etc being in a common module usable by the other classes now and any future
sub-projects which may not want to depend on all the other pieces of the whole (what ever
that may become).


Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member

View raw message