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.
