river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <mmcgr...@topiatechnology.com>
Subject Re: Split JavaSpaces and JINI
Date Mon, 08 Dec 2008 16:17:00 GMT
Hi, John,

Great response!  Or, in the legal profession, I guess this would be a  
surreply.  Great in any case!  I am not suggesting the demise of JINI  
in any sense.  I am just saying that making JINI dependent on  
JavaSpaces would appropriately decouple the two and would allow each  
to be cohesive.  If someone wanted to build a competitor to JINI, if  
things were so changed, they could do so without jettisoning  
JavaSpaces.  Additionally, I believe much of the unwanted complexity  
of JINI would be assisted.


On Dec 8, 2008, at 3:57 AM, John Sarman wrote:

> Well I'm am not the one to ask that, I have been called a Jini  
> zealot more
> than once in my life.  In fact I would be highly upset if that were to
> happen.  I could not imagine JavaSpaces without Jini.  One example, I
> created a hypercube of COTS for a undergrad project.  It simulated a
> parallel computer infrastructure with PCs.  In that I used the  
> JavaSpaces as
> a work pool and had each machine (running rio) fight for work.  No  
> master
> involved.  I completed the task in 3 weeks.  I could not image  
> creating such
> a large project with one person in a 3 week timeframe that was so  
> powerful.
> If the only technology I had would have been Javaspaces, then I  
> would not
> have been able to take advantage of placing a smart proxy as in the  
> Space
> via an Entry class and consuming that so that the 2 machines could  
> do data
> intensive transactions without having to push all the data through the
> space. I think you should give Jini one more shot! In fact a good  
> experiment
> would be to try this:
> https://user-jwfmcclain.dev.java.net/holowaa/holowaa.html.  It is the
> technology I used for the data intensive operations.  It is a  
> wonderful
> example of why the two technologies are both important.
> John
> On Sun, Dec 7, 2008 at 10:50 PM, Michael McGrady <
> mmcgrady@topiatechnology.com> 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?
>> 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 <
>>> mmcgrady@topiatechnology.com> 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
>>>> mmcgrady@topiatechnology.com
>> Michael McGrady
>> Senior Engineer
>> Topia Technology, Inc.
>> 1.253.720.3365
>> mmcgrady@topiatechnology.com

Michael McGrady
Senior Engineer
Topia Technology, Inc.

View raw message