Hello, Holger,
Here is where I am coming from.
I am relatively new to the more detailed issues relating to JINI and
JavaSpaces.
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.
MG
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.
1.253.720.3365
[EMAIL PROTECTED]
