See infra:
On Dec 12, 2008, at 1:19 PM, Gregg Wonderly wrote:
Jini is a system for building distributed system. JavaSpaces uses
the facilities of the Jini system to provide a distributed memory
subsystem. Is that something that you don't see?
Yes this is something I do not see. JavaSpaces as a Linda spaces
implementation is not dependent on JINI in this way.
A Linda space implementation doesn't have to use Jini because it's
not a technology, it's a mechanism/architecture that can have
infinite implementations. Search for "Java Linda Space" on google.
Lots of people have created implementations of a Linda like space
"thing" in Java.
A Linda space implementation is a technology. Implementations don't
have implementations infinite or finite.
I would like to have a Linda spaces implementation, which JavaSpaces
claims to be, by the way, without having to choose yea or nay on
JINI. You are forcing that choice in JINI. That forced choice could
be excised and those other implementations of Linda spaces in Java
could become secondary to JavaSpaces. Further, this would not hurt
JINI at all. Win/win, as i said before. Why would you fight against
this?
JavaSpaces uses features of Jini to participate with other Jini
enabled services so that they can utilities a Linda tuple-space for
distributed memory. If the Entry interface was in JavaSpaces and
not in Jini, than it would have an identical copy in Jini so that
service registration and lookup could use it, since it's in that API
too.
First, if the entry interface was in JavaSpaces, it would not need a
copy in JINI. JINI might need a different implementation that was
more specialized than the JavaSpaces implementation, as Niclas has
noted, but that is good, not bad.
You might think, that's okay, no problem. But, it is a problem for
developers because they'd always wonder which one was being used
when they saw the text Entry. So, you might say, they can have
different names like SpaceEntry and ServiceEntry etc. Well, perhaps
so, but that's water under the bridge. At this point, there are
existing Jini services all deployed with the existing type hierarchy
and class structure. If you change that in an incompatible way,
then you've broken Jini as a concept related to portability and
inter-working services and clients.
If there were only one hierarchy, Gregg, it would not be disturbed by
restructuring and moving the entry interface to JavaSpaces. It would
have no effect at all.
Which do you want out of JavaSpaces? The function of Entry related
to read(), put() and take() on the space, with the matching
mechanisms etc, or do you want that and the ability to access the
JavaSpace from another machine (or two, or more)?
If you want a network, you need network technologies to do that. If
you want reliability in the flow of your data between systems, you
need Transactions. If you want reliability in the recovery of your
system from partial failure, you need leasing.
Again, which parts of Jini do you think JavaSpaces has no need for?
And I do mean NO NEED FOR.
I don't want to get rid of anything. I just want the structure of the
framework, of JINI and JavaSpaces to make sense. Presently, in my
opinion, the structure does not make sense, which accounts for all the
activity around JINI but excluding JINI. People are building things
they need but JINI precludes, even though with proper structuring it
would not have to preclude these uses. The time to change is now
because spaces is being discovered and is passing River by at this
time. I am going to use spaces and I am going to use it in large,
interesting, applications. If River is not changing, then it won't be
River.
Mike
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
