river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: Split JavaSpaces and JINI
Date Mon, 08 Dec 2008 17:33:12 GMT
On 12/8/08, Michael McGrady <mmcgrady@topiatechnology.com> 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.


> 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
> mmcgrady@topiatechnology.com

View raw message