Thanks, Greg,
There is no reason to couple lookup to spaces even though lookup is
absolutely required. Decoupling the lookup from the spaces would
allow different lookup implementations but more importantly it would
allow both the lookup and the spaces to be cohesive.
Low cohesion is architecturally a prime and virtually certain cause of
unnecessary complexity, including the coupling of lookup to spaces.
Is there authorization to send images (GIGs, PDFs) in the emails to
this list. If so, this would be easier to illustrate than to explain.
Mike
On Dec 8, 2008, at 10:01 AM, Greg Trasuk wrote:
On Mon, 2008-12-08 at 12:18, Michael McGrady wrote:
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.
I can understand the view that JavaSpaces is an "application" on top
of
Jini, therefore could be separated. But I don't get what you do with
JavaSpaces sans Jini. As someone else pointed out, how do you lookup
your space without Jini?
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.
Could you perhaps expand on what unnecessary complexity you see?
Mike
Cheers,
Greg.
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[EMAIL PROTECTED]
