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


 ==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

Mime
View raw message