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] > > > > >
