river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Ramsdale <jeff.ramsd...@gmail.com>
Subject Re: Space/outrigger suggestions
Date Wed, 15 Dec 2010 21:12:07 GMT
Yes, I am. But I think there is a class of test and/or app that
benefits from not requiring a StaticCybernode (which is a great
addition to Rio, btw) and corresponding opstring to make use of a
local JavaSpace.

JavaSpaces is the one part of Jini that I would possibly find useful
outside of a Jini service cluster but currently it's not really
possible to use it in that fashion. It could be that with
Leases/Transactions/etc. it is still inherently too Jini-ish to use
independently, but I wanted to introduce the idea of embeddable
Outrigger to the conversation.


On Wed, Dec 15, 2010 at 12:14 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
> Jeff,
> Arent you doing this now with Outrigger & Rio?
> Dennis
> On Dec 14, 2010, at 220PM, Jeff Ramsdale wrote:
>> 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.
>> -jeff
>> 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
>>>>> 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