Although probably not well known, River 3.0's remote method calls are
communicated at native socket speed.
I have considered writing deflate endpoints for JERI, which would
compress and further improve throughput, one case against doing so is,
when compression is used with encryption, there is a possiblity that an
attacker may use a side channel attack to break the encryption, by
causing an endpoint to transmit known data, the attacker can then
determine the keys.
Of course if we really want to make River attractive to new users, it
has to be secure, fast and easy to use.
There are many serialization frameworks out there now, the most popular
are selected because of their speed, but while fast, most are insecure,
or operate without a security manager. Now there's one thing for sure,
no other security manager on the face of this earth will match the speed
or scalability of River's security manager.
So as security becomes more of an issue, we can breath new life into
River by addressing our known security issues and ensuring that we also
achieve optimum performance.
Cheers,
Peter.
On 12/09/2017 9:57 PM, Peter wrote:
Thanks Bryan,
Be good to have a release to address the memory bug (no pun intended).
Even better will be future binary releases based on Modules. Services
built with modules are so much simpler. But so no one gets upset, all
existing build tools, systems and conventions will continue to work too.
Cheers,
Peter.
On 12/09/2017 6:55 AM, Bryan Thompson wrote:
Peter,
Just reviewed the release. My apologies for taking so long to get
this done. It's been a busy time. Thanks for all the effort to pull
this together.
Bryan
On Fri, Jun 16, 2017 at 12:42 AM, Peter<j...@zeus.net.au> wrote:
Anyone have some cycles to participate in the release vetting process?
River 3.0.1 is a bug fix release.
Remember if we're unable to continue this project, then we lose the
ability
to maintain River / Jini and we also lose the legal protections and
visibility of Apache.
Apart from modularity (which lowers technical barriers to entry) and
improved security, I think the most important upcoming feature is IPv6
support, it would be ironic to see River fall over before IPv6 becomes
ubiquitous, given that the deficiencies of IPv4 is likely
responsible for
Jini's failure to gain widespread adoption.
Note also that in spite of "new features" River remains backward
compatible
(in the net.jini.* namespace) with earlier releases. I'm also
working on a
compatibility layer for easier migration away from com.sun.jini to
org.apache.river namespaces.
We can't do it by ourselves, we need you too.
Regards,
Peter.
