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
historically.
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".
Mike
