river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River - 3.0.0 Release candidate
Date Sat, 09 Jan 2016 23:34:14 GMT
 
I have found that discussing even the simplest changes have become labourious.  I understand
that people can be very passionate about Jini.  It's refreshing posting to other projects,
attitudes are much more positive and I think that's because those projects have established
a clear set of goals.

I'm glad jmm compliance is 98% complete,  there are still likely to be a few issues in the
qa suite, but now the brittlness has gone, I can make changes without something breaking.

With ipv6 the shackles of NAT will be removed.  

Right now we have http and https jeri endpoints, we can already do the client server model
of the internet, albiet with dodgy security.  But we can't to p2p now between different local
networks behind nat.

Ipv6 will enable global discovery.  And it will enable peer to peer services.  File sharing
anyone?

IPv6 will redefine the internet, it's a game changer and deployment is going exponential.

The only way to stop River on the internet, is to not implement support for ipv6 discovery.

If we are to tackle the internet with ipv6 we'll need a much more positive, interactive and
collaborative development environment.

We may need to create a place where those who are interested can discuss that and flesh it
out, then we could present it to the wider River community for comment.

As a developer I need to be part of a team, as that creates better api and code than I can
create alone.

Peter.

Sent from my Samsung device.
 
  Include original message
---- Original message ----
From: Patricia Shanahan <pats@acm.org>
Sent: 10/01/2016 06:26:05 am
To: dev@river.apache.org
Subject: Re: River - 3.0.0 Release candidate

I am looking forward to a very open strategy discussion once we get 3.0  
done. I hope everyone will focus during that on ideas and logical  
arguments supported by facts, rather than on personalities. 

On 1/9/2016 12:16 PM, Gregg Wonderly wrote: 
> I sent Greg Trasuk a private note asking him to cease and desist on 
> public badgering and instead to just step back and let the community 
> vote on what happens with River, as that is the process that is 
> supposed to work.  I suggested that if he had a plan and members to 
> vote that plan through, that he could have things however he wanted. 
> I really do not appreciate his attitude and lack of appreciation for 
> the experience and expertise that others have which is different from 
> his own.  I don’t want to badger or belittle him in any way.  But, we

> need to use this process and work through issues by using our brains 
> and our experiences both.  The “web” as we know it, is “mobile code”

> just like Jini uses.  Javascript won, because it was controlled by 
> the browser camp, not by Sun  Applets were in the browser first, but 
> the size of PCs memory and computational resources were no where near 
> mature enough for Java to have won.  I know, I tried to deploy lots 
> of Java in Applets and applications in that time, to the desktop, but 
> there was just not enough money spent on desktop machines in the 
> enterprises where my customers were.  I am, hopefully going to get 
> back out of the .Net world and back into Java and Jini again, this 
> coming year.  I am looking forward to that! 
> 
> Gregg 
> 
>> On Jan 8, 2016, at 5:56 AM, Peter Firmstone 
>> <peter.firmstone@zeus.net.au> wrote: 
>> 
>> The Apache River 3.0.0 Release candidate is available here: 
>> 
>> http://people.apache.org/~peter_firmstone/ 
>> 
>> Voting on this release will commence in 4 weeks, to allow time for 
>> people to check they can reproduce these artifacts and test their 
>> code and report back with any issues. 
>> 
>> The code is currently in trunk, this will be branched after the 4 
>> week review period and Voting passes. 
>> 
>> See also http://www.apache.org/dev/release-publishing.html 
>> 
>> Regards, 
>> 
>> Peter. 
> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message