Hi, John,
Great response! Or, in the legal profession, I guess this would be a
surreply. Great in any case! I am not suggesting the demise of JINI
in any sense. I am just saying that making JINI dependent on
JavaSpaces would appropriately decouple the two and would allow each
to be cohesive. If someone wanted to build a competitor to JINI, if
things were so changed, they could do so without jettisoning
JavaSpaces. Additionally, I believe much of the unwanted complexity
of JINI would be assisted.
Mike
On Dec 8, 2008, at 3:57 AM, John Sarman wrote:
Well I'm am not the one to ask that, I have been called a Jini
zealot more
than once in my life. In fact I would be highly upset if that were to
happen. I could not imagine JavaSpaces without Jini. One example, I
created a hypercube of COTS for a undergrad project. It simulated a
parallel computer infrastructure with PCs. In that I used the
JavaSpaces as
a work pool and had each machine (running rio) fight for work. No
master
involved. I completed the task in 3 weeks. I could not image
creating such
a large project with one person in a 3 week timeframe that was so
powerful.
If the only technology I had would have been Javaspaces, then I
would not
have been able to take advantage of placing a smart proxy as in the
Space
via an Entry class and consuming that so that the 2 machines could
do data
intensive transactions without having to push all the data through the
space. I think you should give Jini one more shot! In fact a good
experiment
would be to try this:
https://user-jwfmcclain.dev.java.net/holowaa/holowaa.html. It is the
technology I used for the data intensive operations. It is a
wonderful
example of why the two technologies are both important.
John
On Sun, Dec 7, 2008 at 10:50 PM, Michael McGrady <
[EMAIL PROTECTED]> wrote:
Thanks, John. I agree with everything you say. However . . .
but . . .
why not do what it takes to split them? Why not put all the classes
necessry to do JavaSpaces in JavaSpaces? Now would be the time to
do it, if
ever? If one of JavaSpaces or JINI has to "wear the pants",
shouldn't it be
JavaSpaces and not JINI, i.e., shouldn't JINI depend on JavaSpaces
and not
the reverse?
Mike
On Dec 7, 2008, at 6:52 PM, John Sarman wrote:
Mike,
Besides the Blitz standalone JavaSpaces, I am not aware of
JavaSpaces
implementation that is usable without Jini.
Even then you still need jini core at a minimum at least to
compile the
JavaSpaces interfaces. For example Javaspaces uses the jini Entry
Specification, the jini event Specification, the jini Transaction
Specification, etc. So the technology is tightly coupled to the
core
specification of Jini. So to breakoff Javaspaces to "grow on its
own" is
not possible without including the core. I would suggest checking
out Dan
Creswell's Blitz project http://www.dancres.org/ because he broke
off
JavaSpaces and grew it in his own GPL way.
Also check out http://www.jini.org/wiki/JavaSpaces_Specification
to see
exactly all the Jini JavaSpaces couplings.
John Sarman
Systems Engineer
TetraCam Inc.
On Sun, Dec 7, 2008 at 9:16 PM, Michael McGrady <
[EMAIL PROTECTED]> wrote:
I have not read all of the threads but in terms of future
directions, has
anyone considered breaking off JavaSpaces from JINI so that
JavaSpaces
could
grow on its own. My interest is JavaSpaces, not JINI at this time.
MIKE
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[EMAIL PROTECTED]
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[EMAIL PROTECTED]
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[EMAIL PROTECTED]
