I am not a committer but I'll express my opinion anyway. I agree with Dennis that the best thing for River is getting out of incubation.
Sean On Tue, Apr 14, 2009 at 5:35 AM, Dennis Reedy <[email protected]> wrote: > 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. > > Regards > > Dennis > > 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 >>>> # >>>> 62.177.181.217 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. >>>>>> >> > >
