The degree of significance depends on whether it would be done as a
change to the existing interface, or as an additional interface.
At first sight, it looks to me as though there is a possibility of
having two thin interfaces, one the existing JavaSpaces and the other a
new Apache River Spaces, on top of a 99% common implementation. The
existing interface would continue to be maintained and benefit from e.g.
performance enhancements.
If we do this, we should take time to think through the new interface
very carefully, to make sure we are willing to live with the new
interface for a long time. We don't want to do something like this every
couple of years.
In any case, I think the comments about javadoc should be considered
separately. Making documentation clearer rarely does any harm.
Patricia
Mike McGrady wrote:
I probably do not need to say that this is a very significant change and should be justified by the most dire need.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 14, 2010, at 2:24 AM, Sim IJskes - QCG <s...@qcg.nl> wrote:
On 12/14/2010 11:07 AM, Patricia Shanahan wrote:
Who controls the JavaSpace API specification? Is it something we can
change, as part of River, or do we just have an implementation?
Should we be considering designing RiverSpaces, similar to JavaSpaces
but with an updated API, including generics, more use of collections,
and better naming?
I think we should be free to change the specifications. RiverSpaces would be a
good thing, to signal deviation from the original specs.
Apache River Spaces would probably be the official name, for trademarks sake.
But in order to be sure, we should take this up with legal-disc...@.
Gr. Sim
