river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Split JavaSpaces and JINI
Date Sun, 14 Dec 2008 18:12:17 GMT
Michael McGrady wrote:
> A more apt comparison would be to have a record outside the sq. 
> package.  That is akin to an entry being outside the spaces package.

Let's see, my example illustrated passing a String into an API that would store 
the string.  How is that not parallel to JavaSpace.put()?

> There are many dependencies that should be decoupled and many others 
> that should not be decoupled, and your example of String in java.lang.* 
> and java.sql.* is one.

That's my point.  Some things are core to a system while others are core to a 
package/service.  Entry is a Jini System class, not a JavaSpace only class.

> I refer you back to my little list of reasons and ways to decouple and 
> reasons and ways to increase the cohesiveness of classes.  There are 
> different types of dependencies.  The decisions must be thought through 
> and justified.

I'm still unexcited by your continuance in citing ignorance as our problem when 
you continue to announce that you know nothing about the details of Jini yet you 
are demanding that the details be changed to meet your ignorant viewpoint.

I've asked for examples of how the compatibility of a new JavaSpace API that 
used it's own Entry type would be compatible with the existing services and 
clients so the people could role out a new instance of JavaSpace without 
breaking their existing clients.  Can you help me understand how that issue 
would be addressed.  At some point, the rubber has to hit the road and things 
have to be possible.

Gregg Wonderly

Mime
View raw message