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?
Alas, such a reversal of dependencies would be quite difficult as for example the Entry Specification that is part of Jini Core is in fact used for lookup (and the lookup service), not just JavaSpaces. Personally I think a more interesting question is: "What do you gain by not bothering with the Jini part?" Seemingly you would lose dynamic lookup unless you replace it with some other mechanism (e.g. Bonjour). Losing this element means a bunch of non-scalable brittle configuration to worry about. Not too mention that absence of this pattern makes for less failure tolerant code and reduces your ability to do dynamic upgrade. If you take away code downloading your ability to have a system dynamically learn about new types (such as might be useful for a compute server) will be lost. Some will claim that with most containers having very poor classloader structures this isn't a loss but personally I'm not a fan of huge long classpaths that leave lots of options for mistakes. A few starters for ten, Dan. > > Mike > > > On Dec 7, 2008, at 6:52 PM, John Sarman wrote: > >> Mike, >> Besides the Blitz standalone JavaSpaces, I am not aware of JavaSpaces >> implementation that is usable without Jini. >> Even then you still need jini core at a minimum at least to compile the >> JavaSpaces interfaces. For example Javaspaces uses the jini Entry >> Specification, the jini event Specification, the jini Transaction >> Specification, etc. So the technology is tightly coupled to the core >> specification of Jini. So to breakoff Javaspaces to "grow on its own" is >> not possible without including the core. I would suggest checking out >> Dan >> Creswell's Blitz project http://www.dancres.org/ because he broke off >> JavaSpaces and grew it in his own GPL way. >> Also check out http://www.jini.org/wiki/JavaSpaces_Specification to see >> exactly all the Jini JavaSpaces couplings. >> >> John Sarman >> Systems Engineer >> TetraCam Inc. >> >> On Sun, Dec 7, 2008 at 9:16 PM, Michael McGrady < >> [EMAIL PROTECTED]> wrote: >> >>> >>>> >>> >>> >>> I have not read all of the threads but in terms of future directions, >>> has >>> anyone considered breaking off JavaSpaces from JINI so that >>> JavaSpaces could >>> grow on its own. My interest is JavaSpaces, not JINI at this time. >>> >>> MIKE >>> >>> 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] > > > > >
