Participation

[Peter <ji...@zeus.net.au>]

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.

Re: Participation

[Peter <ji...@zeus.net.au>]

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<ji...@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.
>>>
>>>
>
>

Re: Participation

[Peter <ji...@zeus.net.au>]

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<ji...@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.
>>
>>

Re: Participation

[Bryan Thompson <br...@blazegraph.com>]

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 <ji...@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.
>
>