river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Hoffstätte <hol...@wizards.de>
Subject Re: Split JavaSpaces and JINI
Date Tue, 09 Dec 2008 16:47:23 GMT
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

Mime
View raw message