Thanks, Holger,
The idea is not to jettison but to decouple JINI from JavaSpaces.
Similarly, in part, various Web frameworks (e.g., Struts) are
decoupled from Servlets. Without something like JINI, JavaSpaces
would be useless but this is different than creating a situation where
JINI itself, rather than something like JINI, would be required.
The idea too is not to suggest that JINI is something that needs to be
replaced. The idea, rather, is that it needs to be decoupled to
follow architectural best practices and that the lack of cohesion in
JIN:-JavaSpaces due to the coupling is not a good thing and can be
seen as the reason for a lot of the unnecessary complexity in River.
Mike
On Dec 8, 2008, at 7:43 AM, Holger Hoffstätte wrote:
Michael McGrady 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?
And how you would look up your JavaSpace "without Jini"?
Jini by itself doesn't really do anything useful, the services are
key -
but that means they have to depend on the foundation. You don't have
to
use the foundation if you don't have to, though the Entry interface
is a
good example for why things are (and have to be) the way they are.
-h
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[EMAIL PROTECTED]
