----- Original Message ---- > From: Gregg Wonderly <[email protected]> > To: [email protected] > 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
