I agree. That would be ideal, to my way of thinking.
Mike
On Dec 8, 2008, at 9:33 AM, Robert Burrell Donkin wrote:
On 12/8/08, Michael McGrady <[EMAIL PROTECTED]> 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.
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.
Open development projects with larger monolithic codebases often find
it harder to recruit developers. Learning a large codebase is a
considerable investment and the process of earning trust takes longer.
It's common at Apache (and elsewhere) for projects to be composed of a
number of sub-projects or products sharing the same develment team. So
River could easily maintain both JINI and JavaSpaces products.
Robert
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]
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[EMAIL PROTECTED]
