----- Original Message ---- > From: John McClain <[EMAIL PROTECTED]> > To: river-dev@incubator.apache.org > Sent: Tuesday, December 9, 2008 11:34:47 AM > Subject: Re: Split JavaSpaces and JINI > > Michael McGrady wrote: > > Thanks, Greg. I think your worries are misplaced. There is nothing in the > suggestion regarding splitting JavaSpaces and JINI that will affect JINI > negatively. > > > > There is no question, I think, of "taking JavaSpaces our of JINI". Rather, > the idea is to decouple them. > > > > Modern computing, as you know, is in large part all about how to properly > organize complex systems. Two related tools are to decouple modules and to > make > sure that a module has high cohesion. So, all that is being discussed here > is > how to decouple, not a divorce. This may only require moving the Entry > interface over to JavaSpaces. > When talk about moving the Entry interface over to JavaSpaces, what does that > mean? Move the package it is in, change the project it is in? What will that > do > to the lookup service interface that also depends on Entry? What about the > other > net.jini.core dependencies JavaSpaces has (leasing, events, and transactions)?
John McClain...who ran for President? heh heh kidding....I know the names are different, I just couldn't resist :-D But, yes, this is what I don't understand either. Seems where we have been talking about breaking things out more modular is what can take care of some of this. Essentially there are some shared classes between JavaSpaces and other Jini things, and those could be a jini-common.jar kind of thing. This to me isn't an issue. There will always be some coupling of some APIs. There is no way to achieve full on decoupling. Same as we have String and it is used *everywhere*. NetBeans Lookup is used to decouple many things. However, many things use Lookup. It works like this: JavaProject extends Project Class -getLookup() -getProjectDirectory() RubyProject extends Project Class -getLookup() -getProjectDirectory() Then each of their Lookups provide things specific to those project types. For instance, Java projects don't know anything about Ruby, so data loaders, file editors, all kinds of things you can think of including project customization specifics are held in this lookup. Then folks find a Project using another Lookup, and all they know is it is a Project type, and then depending on what they need to do with their code they can operate on the project if they know what kind it is and what object instances are availble in the Lookup, and the Lookup itself allows this discovery: Project jp = ...//we lookup the Java project Lookup lu = jp.getLookup(); ProjectConfiguration pc = lu.lookup(ProjectConfiguration.class); or you can even lookup more specific and fine grained things unique only to that project type...such as classes. Now, that is pretty decoupled. Though, at times this kind of decoupling can become very complex in itself, and without great documentation on each implementation this gets horrible, most specific project types are not that easily understood with digging through source code, but technically this is what spaces provides now though you have a JavaSpace and Entries and then any classes you need for your specific parts; JavaSpaces is technically the Lookup. Of course there is Transaction and Lease. So, yes, what exactly needs decoupled and what can't be done? Wade
