river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jgr...@simulexinc.com
Subject Re: Space/outrigger suggestions
Date Tue, 14 Dec 2010 19:37:08 GMT
I second this.   Adding to Jira.

I believe some third-party implementers have provisions for functionality like this, but it
would be a welcome addition to outrigger.

This is specifically regarding the implementation, outrigger, and not the protocol/interface
layer Javaspace.   On face value, it's not unreasonable for the implementation to provide
for a remote/service layer and a core datastructure that the remote layer perhaps also uses.
  Not sure how easy to implement it would ultimately be.

In addition to unit testing and local message passing, perhaps a locally instantiated javaspace
might also have uses in coordination between threads?


-----Original Message-----
From: "Jeff Ramsdale" <jeff.ramsdale@gmail.com>
Sent: Tuesday, December 14, 2010 2:20pm
To: river-dev@incubator.apache.org
Subject: Re: Space/outrigger suggestions

I'd like to be able to work with a Space without having to mess with
Jini's service starter. If I could instantiate a space locally and
control its lifecycle in my app it would be easy to use it (say) in
the context of unit testing my components or as an embedded message
broker in my app.


On Tue, Dec 14, 2010 at 11:03 AM, Patricia Shanahan <pats@acm.org> wrote:
> Could you expand on what you mean by "embedded mode" in this context?
> On 12/14/2010 11:00 AM, Jeff Ramsdale wrote:
>> If this common implementation lends itself to an embedded mode it
>> would be a boon for familiarizing oneself with the Spaces paradigm as
>> well as testing. Something to keep in the back of your mind as you're
>> delving into this...
>> -jeff
>> On Tue, Dec 14, 2010 at 9:55 AM, Patricia Shanahan<pats@acm.org>  wrote:
>>> 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

View raw message