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
