I have given you my answer but I will do so again.
I think JINI is conceptually dependent on JavaSpaces. No JavaSpaces,
no JINI, conceptually.
JavaSpace is not dependent on JINI. No JINI, no worries,
conceptually. That is only a problem now because interfaces that
should be in JavaSpaces are in JINI.
I think that JavaSpaces must include certain features, e.g., entries,
operations on entries, etc. This is the core technology to my way of
thinking. There is no cookie cutter exact answer to exactly where to
draw the line. JavaSpaces should be completely independent of JINI.
JINI should be intelligence on top of JavaSpaces with a different and
additional purpose.
Mike
On Dec 11, 2008, at 6:37 PM, Gregg Wonderly wrote:
Michael McGrady wrote:
The idea of having JavaSpaces be dependent upon JINI rather than
vice versa has no justification that I can see. Why would you do
that?
Michael, you keep saying this without illustrating which parts of
Jini JavaSpaces shouldn't use.
Can you describe the type structure that you would convert all the
things in the JavaSpace interface API to which would allow a new
JavaSpace with your described independence work in an environment
with applications that use the current JavaSpace? That might help
us understand the path of adoption into existing application bases.
Gregg Wonderly
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
mmcgr...@topiatechnology.com
