I guess we have some communication issues here which are probably
wholly due to me, myself and I.
I tried to signal what I was thinking with "conceptually" highlighted
as much as possible and as opposed to, for example, "physically".
Your comments merely emphasize the point I was trying to make. I am
interested in what it takes to employ, to deploy, etc. JavaSpaces. I
would like to do so without having the kitchen sink of JINI thrown
in. You are agreeing that indeed JINI is a kitchen sink with respect
to this issue.
Can you see how to distinguish between "is dependent now" and "is not
conceptually dependent" and even "should not be dependent"? I am
surprised how many members of this list see fact as logic.
Mike
On Dec 11, 2008, at 7:32 PM, Dominic Cleal wrote:
On Thursday 11 December 2008 23:54:43 Michael McGrady wrote:
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. [..snip, DC..]
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.
I have to jump in at this point and ask if you have ever used Jini
without
JavaSpaces? Why do you think Jini is somehow dependent upon
JavaSpaces and
what's your justification?
It's entirely possible to use all manner of Jini services without
any need for
a JavaSpace. Your distributed system doesn't require a JavaSpace to
be "conceptually" valid. Jini is more than you're making it out to
be.
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.
JavaSpaces is dependent upon Jini's transaction specification, which
includes
the transactions themselves (which are dependent on leasing) and the
transaction managers (Jini-based services themselves). There are
more than
just a few interfaces in all of that.
The JavaSpaces specification is simply an example of a Jini
service. It's a
specification many of us are fond of, but it is a specification
based on
various underlying Jini technologies and ideas.
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.
I've a feeling we'd be left with many valuable offcuts if you were
holding the
cookie cutter.
JavaSpaces should be completely independent of JINI.
JINI should be intelligence on top of JavaSpaces with a different and
additional purpose.
Please don't leave us hanging; what purpose needs Jini to be based on
JavaSpaces?
--
Dominic Cleal
CDO2
Albert Buildings
49 Queen Victoria Street
London
EC4N 4SA
Tel: +44 (0)845 456 4460
Fax: +44 (0)845 456 4461
www.cdo2.com www.cdovar.net
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
