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 Wed, 10 Dec 2008 03:09:30 GMT
Hello, Holger,

Here is where I am coming from.

I am relatively new to the more detailed issues relating to JINI and  

I got here due to some pretty formidable issues in network computing  
involving scaling and performance that looked like JavaSpaces could  
definitely help.  The basic ideas behind JavaSpaces made sense and  
were not even challenging, even though exciting and I think rather deep.

When I ran into the JavaSpaces and JINI mix, I was surprised at the  
"messiness" of it all.  I find that clean code that makes immediate  
semantic sense is pretty necessary in the jobs I do.  I pretty much  
have to ensure ultraquality not unlike aerospace and nuclear power  
plant issues.  Also, I have to consider pretty severe security issues  
and having extra functionality in a code base where it seemingly does  
not belong becomes an issue in a heartbeat.

For me the current codebase is not very usable.  I would prefer to  
have a JavaSpaces API that allowed a full use of JavaSpaces (Linda  
spaces as it were) and to keep JINI aside for whatever extras there  
were outside that.


On Dec 9, 2008, at 11:47 AM, Holger Hoffstätte wrote:

> Michael,
> I am still not sure what exactly you would gain, in practical terms.  
> Why
> would you want to decouple the two when the individual parts are not
> particularly useful without each other? This might be useful if we had
> complicated build dependencies or huge jars that become too big or
> cumbersome to buid/test, but none if this is the case at the moment.
>> is being discussed here is how to decouple, not a divorce.  This may
>> only require moving the Entry interface over to JavaSpaces.  That  
>> "plain
> Entry just marks things so now every regular service lookup would  
> depend
> on JavaSpaces? That makes no sense. The only possibility out of this  
> might
> be two different interfaces, one for Jini lookups and one for marking
> space entries, but again what's the gain? It's just an interface. If  
> you
> treat the Jini core classes as "just another library" instead of  
> like an
> intimidating machinery with mobile code and whatnot, the entire  
> issue goes
> away.
> I wrote my first few JavaSpaces examples and happily used some of  
> the Jini
> core classes (like remote events) without knowing one bit about the  
> details.
>> The Javaspace API is of interest independent of JIN, as others have
>> pointed outI.  If River won't decouple them, then that is an  
>> unnecessary
>> limitation of the codebase which would be unfortunate for a project
>> seeking interested people.
> I get the impression that somehow you really want "something else",  
> i.e.
> the functionality of JavaSpaces without Jini..? If so please explain  
> what
> and why - just curious.
> Holger

Michael McGrady
Senior Engineer
Topia Technology, Inc.

View raw message