I agree with your argument and add that when JavaSpaces operations on
entries come into play in a network, those operations should be in
JavaSpaces interfaces. There should be, in other words, a fully
workable JavaSpaces API without JINI.
MG
On Dec 11, 2008, at 9:04 PM, Niclas Hedhman wrote:
On Fri, Dec 12, 2008 at 9:40 AM, Michael McGrady
<mmcgr...@topiatechnology.com> wrote:
Imagine that in order to use Log4J you had to setup JINI because an
interface important to Log4J were in JINI. This problem would not
be solved
by pointing out that you can use JINI without Log4J. And, if
someone said
they thought Log4J was conceptual independent of JINI and should be
made so
in its interfaces, that would be a good point. It would not be a
retort to
say that Log4J would not work in these conditions without JINI.
Am I clear?
But you were! saying that Jini should be depending on JavaSpaces and
not the other way around as is now the case. Why? Jini is about
Service Discovery, and why would a Space implementation be a backbone
of that?
My argument is that River should have a JavaSpaces implementation that
does not require a network setup, as a stepping stone to lower the
threshold of River adoption. (The "First Shot is Free" comes to mind.)
Cheers
Niclas
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
mmcgr...@topiatechnology.com
