river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: JSC - Seven
Date Tue, 14 Apr 2009 11:35:53 GMT
I for one think we need to focus on getting a River release out there,  
and moving River out of incubation. Getting into a discussion on what  
*external* technology/projects should be included into River as  
optional components at this time is premature.

We could also first asses whether there are current services in River  
that should first be viewed as optional. For example Mahalo,  
Outrigger, Mercury, Norm. I suggest we get this squared away first.

As for whats the best for River and it's ecosystem? As mentioned above:

Get River out of incubation

Once thats done, we can discuss external technology/projects to bring  
in. Certainly there are multiple candidates for this, and based on the  
success of River moving out of incubation I would certainly consider  
adding Rio to the mix here as well.



On Apr 14, 2009, at 715AM, Peter Firmstone wrote:

> Thank you for the polite, informative and open reply.
> Inclusion in River (as an optional component) could / is perceived  
> as an unfair competitive advantage of one projects solution /  
> approach over the others?
> Harvester,
> Rio,
> Seven,
> Bantam.
> Rio is already very successful in its own right, I can't see this  
> being any threat to Rio, Seven doesn't have the features that Rio  
> provides. Bantam is quite popular too, could it have much affect on  
> Bantam?  It probably would affect Harvester (I was unaware of  
> Harvester), is there something here we can learn from both projects?
> All projects share some common ground, however they focus on  
> solutions to different problems and markets, these projects are  
> competing directly?  Should they be viewed as competitors?  No,  
> Different Solutions for different user / customer requirements.  All  
> provide opportunities for service income for those involved.  We  
> must grow the gene pool and encourage adoption by new developers /  
> users.
> All projects based on River / Jini contribute to growth, innovation  
> and possibilities around the River ecosystem.
> What is best for River?
> Would loss of the Seven code base be good for River?  It is  
> certainly approaching obscurity? It appears that the Copyright owner  
> is no longer interested in pursuing Seven's Public project status.   
> Without active promotion it's going to suffer from lack of  
> Visibility and adoption.
> The license is Apache 2.0, which means that the code from the Seven  
> project could be used, we could not however call it Seven or  
> Cheiron, the licensing headers & notices would also need to remain  
> with the code.  The out of the box experience for Rivier , NIO and  
> threading advantages would be nice additions.
> How could integrating the code, which does appear to be a slightly  
> sensitive issue, be best handled, in such a way that benefits /  
> encourages newcomers into the River platform ecosystem?  Against  
> other platform choices?
> At some level these projects are complementary.
> In the most respectful way, and momentarily disregarding the  
> interests of each individual project, what is best for River & its  
> ecosystem?
> Being swallowed by River, would mean that one individual project  
> would cease to exist, its code (many hours of hard work) and tools  
> would continue to evolve and be available for use in other River  
> based projects.
> It would certainly become easier to maintain code compatibility and  
> bring some improvements made in Seven into River.  Considering the  
> lead developer, is also one of the major contributers to River, such  
> a move would reduce his maintenance burden of the Seven codebase,  
> while ensuring the benefits of its creation are not lost.
> Lastly, such a move would assist River in providing the 'Out of the  
> Box Experience' for new users, once they master the basics they'll  
> discover the rest of the ecosystem and find their niche, instead of  
> thinking it too complex, then moving on.
> Commercial platforms typically bundle what used to be separate  
> applications over time, its a matter of survival.
> Best Regards,
> Peter Firmstone.
> Greg Trasuk wrote:
>> I've always felt that the various containers should be kept separate
>> from the Jini core.  As the author of the Harvester application
>> container I'm perhaps a little biased, but I think that there are  
>> many
>> valid containers and approaches to containers out there and River
>> shouldn't play favourites (unless it's Harvester ;-) ).  I'm sure  
>> Mark ,
>> Dennis, Gregg, and others would agree (given different favourites).
>> Also, Mark would have to confirm, but wasn't there some question of  
>> his
>> former employer holding the copyright to Seven's code?  I don't  
>> know if
>> he's free to contribute it to Apache.
>> Cheers,
>> Greg.
>> On Sun, 2009-04-12 at 18:13, Peter Firmstone wrote:
>>> Dennis Reedy wrote:
>>>> I'm not sure how one relates to the other?
>>> Make things easier for new users to get started with River? As an  
>>> optional addition / extension to River.
>>> Mark Brouwer, the project lead, participates in River.
>>> Just a thought, here's some background:
>>> Seven is an implementation of the Jini Service Container Spec.
>>> This blog has an example:
>>> http://blogs.sun.com/warren/entry/jini_made_easier_writing_a
>>> you'll need to add the following to your hosts table to follow the  
>>> link to download seven:
>>> # Internet host table
>>> #
>>> www.cheiron.org scm.cheiron.org issue.cheiron.org
>>> from the Cheiron website:
>>>  Seven
>>> Seven is the 'reference' implementation of the Jini? Service  
>>> Container Specification <http://www.cheiron.org/jsc/index.html>  
>>> that eases the development and deployment of Jini? services and  
>>> provides features such as:
>>>    * manage service registration with various lookup services;
>>>    * support for distributed events, leasing and participation in  
>>> the
>>>      two-phase commit protocol, these can be persisted for  
>>> 'persistent'
>>>      services allowing for crash recovery;
>>>    * administration interfaces for life-cycle and join management  
>>> to a
>>>      service;
>>>    * simple persistence API that can be used e.g. to capture
>>>      transactional state;
>>>    * finding and tracking other services in the djinn;
>>>    * resource management such as allocating threads and leased  
>>> resources;
>>>    * resource efficiency by employing various tactics to reduce the
>>>      number of threads used by many of the Jini implementation  
>>> classes;
>>>    * service configuration, like the RMI runtime, (distributed)
>>>      security, logging and configuration of objects used by the  
>>> service
>>>      itself;
>>>    * controlling codebase annotation and serving download jar  
>>> files, as
>>>      well as versioning of services and downloadable code;
>>>    * standardized packaging format (Service Archive) for Jini  
>>> services,
>>>      see JSC Service Repository
>>>      <http://www.cheiron.org/seven/repository.html>;
>>>    * installation and upgrade of a service and container, services  
>>> can
>>>      be upgraded without bringing the container down and changes to
>>>      mobile code will propagate through the network;
>>>    * complete security support for SSL and Kerberos, also for the
>>>      discovery protocols;
>>>    * role based access control for remote method invocations and for
>>>      authorization decisions within your JSC Service code;
>>>    * all aspects of security are dynamically (re)configurable so  
>>> your
>>>      environment can adapt to new trust relationships;
>>>    * container can be configured through a Jini administration
>>>      interface even the security aspects and service configuration
>>>      data, this enables you create very dedicated provisioning
>>>      solutions on top of Seven;
>>>    * persistency is implemented based on top of a reliable high
>>>      performance transactional storage engine for which data is
>>>      checksummed and provides crash recovery with zero maintenance,
>>>      tuning for various QoS aspects is possible.
>>> The Seven Suite <http://www.cheiron.org/seven/ 
>>> index.html#seven_suite> is Seven together with additional tools,  
>>> examples, manuals, source code and should provide you an out-of- 
>>> the-box experience with Jini?.
>>> The JSC Platform that is part of Seven that incorporates many Jini  
>>> Community Standards is mainly based upon code implemented by the  
>>> Jini? team at Sun Microsystems (Jini? Technology Starter Kit) and  
>>> for which the continued development takes place at the Apache  
>>> River <http://incubator.apache.org/river/> project.
>>>> On Apr 12, 2009, at 811AM, Peter Firmstone wrote:
>>>>> Due to there being no DNS for the Cherion project, would it make  
>>>>> sense to include Seven into River after AR2 as an optional  
>>>>> component?
>>>>> Cheers,
>>>>> Peter.

View raw message