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 Sun, 21 Dec 2008 05:59:15 GMT

On Dec 20, 2008, at 9:14 PM, Wade Chandler wrote:

> Well, spaces is not actually coupled to lookup. To use a space  
> currently in Linda fashion in Jini then yes, you need the lookup  
> stuff, but the spaces themselves are not bound to lookup; not  
> coupled at all.

I agree.  I think there is a real reason for an API separate from  
JavaSpaces.  And, I think calling that JINI would make sense  

> You have this space in a given distributed system, and it must be  
> found. Now, you could very well have a space found by any custom  
> means necessary without anything else from the Jini APIs except for  
> Entry, transaction, and lease. Those other things just happen to be  
> some common concepts which spaces uses. Just because it uses them  
> should not mean they reside in the spaces API or some packing  
> specifically for spaces.

I agree with this too.

> I 100% *disagree* that an entry is useless without a space if we are  
> talking about a JavaSpace versus a generic notion of a memory space  
> of some kind. An Entry is just as valid in different contexts as it  
> is in a JavaSpace. The methods in which it is used are not defined  
> necessarily. There is an expected way of using them as templates and  
> matching for comparing them etc along with expected ways they will  
> be serialized and conversely deserialized.

I don't believe that JINI has no use for a number of entry types. I  
know it does.

I just believe that JavaSpaces needs an entry and that JavaSpaces  
should not be tied to JINI.  JavaSpaces should be conceptually  
independent of the JINI architecture.  JavaSpaces cannot be  
independent if a core interface is a part of JINI.  JavaSpaces itself  
should be independent of JINI, I think.

So, on my view, JavaSpaces Entry should not be JINI Entry and vice  
versa.  Either solution is bad, I think.  Another alternative is  
needed.  There are many.  I think they should be brought up,  
discussed, and so on.

Entry, of course, is just one of the interfaces being discussed.

> That argument aside, there is nothing currently forcing you to use  
> the other things in Jini with spaces, except for those required  
> concepts detailed here, though lookup is the only way to use spaces  
> in the context of a distributed system if all you have is Jini. You  
> can take all the things actually required to use a space, never use  
> lookup, include those things on your classpath, and be on your way.  
> However, you'll have to create an entire architecture to deal with  
> the distributive nature one would normally want to use with a space.
> Maybe that is where you need to focus what you are proposing. I  
> don't think you'll ever convince me or most others those other  
> concepts need to be in spaces as they are very generic and can be  
> used for numerous other things where one may never want spaces.

The idea of an entry is, I agree, generic.  The idea of a spaces  
entry, I think, is not.  I have nothing against and actually would  
prefer an Entry tag interface in Java itself.

> However, you might have something you can detail with respect to a  
> different type of a distribution mechanism to offer some light  
> concepts or something. I think there is a lot there to deal with  
> however which is what the rest of Jini does. You might have or come  
> up with some design which you can get some rudimentary things  
> working to share and prove it. Seems anything really useful if you  
> go that far though would really just be a remote space with some  
> pluggable tranport mechanisms which you could then use other  
> technologies to wrap around it, but truly that sounds like the same  
> thing Jini is/does unless you have some specifics.

This all sounds reasonable and worth consideration.  I do think I  
would need to do a lot more thinking before stepping out on any  
particular path: measure twice, cut once or that good old heuristic  
that seems to be universally true - "all the worst mistakes are made  
on the first day".


View raw message