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
