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. -jeff On Wed, Dec 15, 2010 at 12:14 PM, Dennis Reedy <dennis.re...@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 <p...@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<p...@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 >>>> >>> >>> > >
