On Dec 14, 2008, at 11:56 AM, Wade Chandler wrote:
----- Original Message ----
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).
I use Jini, usually without explicit use of JavaSpaces, so moving the
Entry spec into the space spec would not make sense for me (so I
concur with your concern about making the system less cohesive).
I think that having implementations of various components like the
transaction manager and discovery manager that can execute within the
same JVM with no fuss might be a more prudent direction.
I think the issue that needs to be solved is how to make a better "out
of the box" experience (it just works!) for developers (add the
dependency to your maven project, and make a few reads and writes to a
java space that you create).
Keith
