On Thu, 2008-12-11 at 21:08, Michael McGrady wrote: > I agree with your argument and add that when JavaSpaces operations on > entries come into play in a network, those operations should be in > JavaSpaces interfaces. There should be, in other words, a fully > workable JavaSpaces API without JINI. > > MG >
http://lights.sourceforge.net seems like it might do it for you. Cheers, Greg. > > On Dec 11, 2008, at 9:04 PM, Niclas Hedhman wrote: > > > On Fri, Dec 12, 2008 at 9:40 AM, Michael McGrady > > <[email protected]> wrote: > >> Imagine that in order to use Log4J you had to setup JINI because an > >> interface important to Log4J were in JINI. This problem would not > >> be solved > >> by pointing out that you can use JINI without Log4J. And, if > >> someone said > >> they thought Log4J was conceptual independent of JINI and should be > >> made so > >> in its interfaces, that would be a good point. It would not be a > >> retort to > >> say that Log4J would not work in these conditions without JINI. > >> > >> Am I clear? > > > > But you were! saying that Jini should be depending on JavaSpaces and > > not the other way around as is now the case. Why? Jini is about > > Service Discovery, and why would a Space implementation be a backbone > > of that? > > My argument is that River should have a JavaSpaces implementation that > > does not require a network setup, as a stepping stone to lower the > > threshold of River adoption. (The "First Shot is Free" comes to mind.) > > > > Cheers > > Niclas > > Michael McGrady > Senior Engineer > Topia Technology, Inc. > 1.253.720.3365 > [email protected] -- Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.com
