RE: Lotj - languages other than java

2016-07-04 Thread Bishnu Gautam
Hi Patricia

> 
> Do you have any ideas for how to recruit River developers? Even the 
> committers we have do not have enough time to finish an almost complete 
> release.

Do you have scheme of recruitment with payment or complete volunteers? If it is 
volunteers, internship program would be the mos practical one. In that context 
it is quite possible to recruit developers in River by putting internship 
programs who can work together with active committers or developers in River 
project. If you open internship program, I can also send my students to work 
together online with active members of River project. I think this is the most 
practical solution if they need to work as volunteers. In the beginning we can 
start from a small scale and once someone is ready to contribute enough from 
the internship, then we can scale out with more numbers and in this way, the 
community would be increase. Let me know if you are interested about it.
RegardsBishnu 

Re: Lotj - languages other than java

2016-07-04 Thread Patricia Shanahan

On 7/4/2016 8:33 PM, Bishnu Gautam wrote:

Hi Peter It is great that you pointed out lookup locator issue in
firewall and its potential solution. It would be great to see the
developments in River in which they really focus to have lookup
discovery beyond the firewall without requiring port forward and
other demanding packet filtering techniques. Once this obstacle in
River is crossed, I am pretty sure that there will be new paradigm
shift in IoT or ICT technology. This technology has a tremendous
potential. However, I never understand why River community never try
to bring this issue on the first place. River in Internet would be
the most wonderful solutions for millions of users around the world.
Please think, discuss and try to work on it. It would be a great news
for us.


Do you have any ideas for how to recruit River developers? Even the 
committers we have do not have enough time to finish an almost complete 
release.


RE: Lotj - languages other than java

2016-07-04 Thread Bishnu Gautam
Hi Peter
It is great that you pointed out lookup locator issue in firewall and its 
potential solution. It would be great to see the developments in River in which 
they really focus to have lookup discovery beyond the firewall without 
requiring port forward and other demanding packet filtering techniques. Once 
this obstacle in River is crossed, I am pretty sure that there will be new 
paradigm shift in IoT or ICT technology. This technology has a tremendous 
potential. However, I never understand why River community never try to bring 
this issue on the first place. River in Internet would be the most wonderful 
solutions for millions of users around the world. Please think, discuss and try 
to work on it. It would be a great news for us.
RegardsBishnu


Bishnu Prasad Gautam


> Date: Mon, 4 Jul 2016 18:37:25 +1000
> From: j...@zeus.net.au
> Subject: Re: Lotj - languages other than java
> To: dev@river.apache.org
> CC: si...@qcg.nl
> 
>  
>  
>  
> Sim,
> 
> I'd like to see the project return to the days where we had a number of 
> active committers working together on the same goals.
> 
> I've got a project on github, where I've continued work that was 
> controversial, I'd like to bring this work back to the project if possible.  
> It has some minor breaking changes, but if backward compatibility was 
> essential, it could be accommodated.
> 
> Changes:
> * New secure discovery providers, including https among others, including 
> added https protocol support for LookupLocator.  However since firewalls may 
> not allow ipv6 multicast packets through, DNS-SD would be useful.
> * IPv6 Discovery, global and local groups.
> * Discovery V2 support added to LookupLocator's getRegistrar method.
> * Updated encryption ciphers, removal of insecure ones.
> * Deprecation of ProxyTrust et al.
> * New default methods added to ServiceRegistrar to allow establising trust 
> with a service, prior to obtaining a service proxy, or Entry's (works with 
> both maven codebase provisioning and traditional codebase downloads).
> * Input validation for untrusted serial data.
> * META-INF/permissions.perm files list permissions required by codebase, 
> accessible from ClassLoader using mixin interface.
> 
> I recall you had a need for a SocketFactory in LookupLocator, at that time 
> LookupLocator only used discovery v1, which was deprecated, I'd like to 
> include a way to enable SocketFactory support in discovery V2.  Note that 
> LookupLocator isn't serialized during discovery.
> 
> While the River codebase was a little difficult to understand at first, I 
> find it's quite easy to work with now.  
> 
> While I'm a critic of Rivers flaws, addressing th em is straight forward, the 
> greatest challenge is convincing everyone that flaws exist, or that they need 
> addressing, there's still plenty of good stuff left worth saving.
> 
> Regards,
> 
> Peter.
> 
> 
> Sent from my Samsung device.
>  
>   Include original message
>  Original message 
> From: Peter 
> Sent: 01/07/2016 04:35:16 pm
> To: dev@river.apache.org 
> Subject: Re: Lotj - languages other than java
> 
>  
>  
>  
>  
> Thanks Sim,
> 
> These are all good questions we need to consider.
> 
> I like the model of micro services where each service is responsible for 
> implementing its own back end persistence and state.  Do you consider a 
> microservice to be web based? 
> 
> I have an implementation of discovery using multicast ipv6.  However for 
> firewalls with limited open ports such as https over ipv6, we have JERI https 
> endpoints, but no discovery, DNS-SD is a good discovery alternative waiting 
> to be implemented.
> 
> For my own environment I will be adopting ipv6 , the global address space and 
> autoconfiguration solve many problems that users experience with ipv4 today.
> 
> I admit the locked down api caused me frustration, but I think it's clear now 
> that we need a process for managing api evolution.  
> 
> Complexity - The proxy preparation api tries to determine trust after 
> downloading untrusted code and deserialization of unverified data.  As gadget 
> attacks demonstrate, too little too late at great complexity.  This was an 
> attempt to bolt security onto the existing lookup service.
> 
> JERI is good, method constraints are good, proxy trust is obsolete.  River's 
> current ssl and https JERI endpoints need to be brought up to date as they're 
> no longer secure.  I've already done this work externally, it can be donated 
> when appropriate for the project.
> 
> If we address security issues, we can provide a secure alternative to RMI  
> Oracle has chosen 'whack a mole' security for Serialization, rather than 
> address some fundamental design flaws with ObjectInputStream, for this 
> reason, authentication of the source must occur prior to accepting serial 
> data.  Despite common belief, white listing isn't a completely secure 
> solution and adds conplexity as it's too fine grained.
> 
> For multi language support, this 

Re: Attic? Was: Re: Lotj - languages other than java

2016-07-04 Thread Patricia Shanahan

See https://attic.apache.org/ for an introduction.

The question I am raising is whether River is viable as an Apache 
project, not whether it is a valuable body of code. Your second 
paragraph is exactly my point.


Apache brings some good stuff to its projects in the form of licensing 
with carefully controlled provenance and signed, tested releases. The 
downside is a process that is incompatible with Github, and some 
bureaucracy around the release process.


If that is not currently the right trade-off for River the best thing to 
do is to move to the attic. Any individual, or group of individuals, can 
download the code and use it any way they like that is compatible with 
Apache's license, which allows a lot. In particular, people who agree on 
a direction can start their own Github repository based on the River 
code. They do have to preserve some notices and make it clear that they 
have modified the code. See http://www.apache.org/licenses/LICENSE-2.0 
for details.


Patricia

On 7/4/2016 7:49 AM, Bryan Thompson wrote:

I am just not that familiar with Apache policy.  However, river is a real,
functional, deployed in use platform.   I certainly agree that there is
deadlock at this point in terms of the people and process.  However, I am
not sure that an attic is the right place for a well grounded and fielded
technology.  While the community might not be able to move ahead along a
clear roadmap, there is still support from the community for the technology.

Maybe a move to github would help to break things loose?  Open up the
development and release process more?  Right now things are hung up in part
on Apache process. Maybe Apache is just not the right place at this time
for this technology?

Thanks,
Bryan

On Mon, Jul 4, 2016 at 10:08 AM, Patricia Shanahan  wrote:


I think it is time to raise on the user list moving River to the attic.

There is no sign of progress on a release. What interest there is in
development seems to be going in different directions. Using portions of
River code in other projects would still be feasible with it in the attic,
but there would be no need for a PMC, and board reports.

Patricia

On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote:
...


But then again, there are a lot of people reading this, and a big part
of them having no interest at all in incompatible improvements, and i
see no other option than leaving them behind, with a jini compatible
maintenance release. This will certainly tear the river community apart,
or at least cause a lot of friction. So when i see only the two of us,
moving in a new direction, i can't help feeling, what is the use of it
all.

G. Simon








Re: Attic? Was: Re: Lotj - languages other than java

2016-07-04 Thread Bryan Thompson
I am just not that familiar with Apache policy.  However, river is a real,
functional, deployed in use platform.   I certainly agree that there is
deadlock at this point in terms of the people and process.  However, I am
not sure that an attic is the right place for a well grounded and fielded
technology.  While the community might not be able to move ahead along a
clear roadmap, there is still support from the community for the technology.

Maybe a move to github would help to break things loose?  Open up the
development and release process more?  Right now things are hung up in part
on Apache process. Maybe Apache is just not the right place at this time
for this technology?

Thanks,
Bryan

On Mon, Jul 4, 2016 at 10:08 AM, Patricia Shanahan  wrote:

> I think it is time to raise on the user list moving River to the attic.
>
> There is no sign of progress on a release. What interest there is in
> development seems to be going in different directions. Using portions of
> River code in other projects would still be feasible with it in the attic,
> but there would be no need for a PMC, and board reports.
>
> Patricia
>
> On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote:
> ...
>
>> But then again, there are a lot of people reading this, and a big part
>> of them having no interest at all in incompatible improvements, and i
>> see no other option than leaving them behind, with a jini compatible
>> maintenance release. This will certainly tear the river community apart,
>> or at least cause a lot of friction. So when i see only the two of us,
>> moving in a new direction, i can't help feeling, what is the use of it
>> all.
>>
>> G. Simon
>>
>>
>>
>>


Attic? Was: Re: Lotj - languages other than java

2016-07-04 Thread Patricia Shanahan

I think it is time to raise on the user list moving River to the attic.

There is no sign of progress on a release. What interest there is in 
development seems to be going in different directions. Using portions of 
River code in other projects would still be feasible with it in the 
attic, but there would be no need for a PMC, and board reports.


Patricia

On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote:
...

But then again, there are a lot of people reading this, and a big part
of them having no interest at all in incompatible improvements, and i
see no other option than leaving them behind, with a jini compatible
maintenance release. This will certainly tear the river community apart,
or at least cause a lot of friction. So when i see only the two of us,
moving in a new direction, i can't help feeling, what is the use of it all.

G. Simon





Re: Lotj - languages other than java

2016-07-04 Thread Simon IJskes - QCG
On 04-07-16 10:37, Peter wrote:
> I'd like to see the project return to the days where we had a number of
> active committers working together on the same goals

I'm sorry that i did not immediately answered your email. I think there
needs to be more buy-in for change, than only the two of us.

Also, the needs that i had for a easy communication system are covered
by code developed in house. It allows for send and post, and async
return of exceptions. A deviation from the river model.

Maybe we can restart as a universal library for safe-RMI. With easy
options for connections to and from known (or discovered by outside
means) endpoints, IPv6, poking through UPNP and NAT firewalls,
multi-homed host capable (without -D options on the command line).

Modular addable lookup services, discovery, identity, locking, tspaces,
etc. But at least a system with a very low knowledge threshold, and
small jar footprint to get things working.

We could use a more modern declarative system for specifying security
needs, so that later we could create adapters for in and outbound rpc
protocols with a bigger market reach.

But then again, there are a lot of people reading this, and a big part
of them having no interest at all in incompatible improvements, and i
see no other option than leaving them behind, with a jini compatible
maintenance release. This will certainly tear the river community apart,
or at least cause a lot of friction. So when i see only the two of us,
moving in a new direction, i can't help feeling, what is the use of it all.

G. Simon





Re: Lotj - languages other than java

2016-07-04 Thread Peter
 
 
 
Sim,

I'd like to see the project return to the days where we had a number of active 
committers working together on the same goals.

I've got a project on github, where I've continued work that was controversial, 
I'd like to bring this work back to the project if possible.  It has some minor 
breaking changes, but if backward compatibility was essential, it could be 
accommodated.

Changes:
* New secure discovery providers, including https among others, including added 
https protocol support for LookupLocator.  However since firewalls may not 
allow ipv6 multicast packets through, DNS-SD would be useful.
* IPv6 Discovery, global and local groups.
* Discovery V2 support added to LookupLocator's getRegistrar method.
* Updated encryption ciphers, removal of insecure ones.
* Deprecation of ProxyTrust et al.
* New default methods added to ServiceRegistrar to allow establising trust with 
a service, prior to obtaining a service proxy, or Entry's (works with both 
maven codebase provisioning and traditional codebase downloads).
* Input validation for untrusted serial data.
* META-INF/permissions.perm files list permissions required by codebase, 
accessible from ClassLoader using mixin interface.

I recall you had a need for a SocketFactory in LookupLocator, at that time 
LookupLocator only used discovery v1, which was deprecated, I'd like to include 
a way to enable SocketFactory support in discovery V2.  Note that LookupLocator 
isn't serialized during discovery.

While the River codebase was a little difficult to understand at first, I find 
it's quite easy to work with now.  

While I'm a critic of Rivers flaws, addressing th em is straight forward, the 
greatest challenge is convincing everyone that flaws exist, or that they need 
addressing, there's still plenty of good stuff left worth saving.

Regards,

Peter.


Sent from my Samsung device.
 
  Include original message
 Original message 
From: Peter 
Sent: 01/07/2016 04:35:16 pm
To: dev@river.apache.org 
Subject: Re: Lotj - languages other than java

 
 
 
 
Thanks Sim,

These are all good questions we need to consider.

I like the model of micro services where each service is responsible for 
implementing its own back end persistence and state.  Do you consider a 
microservice to be web based? 

I have an implementation of discovery using multicast ipv6.  However for 
firewalls with limited open ports such as https over ipv6, we have JERI https 
endpoints, but no discovery, DNS-SD is a good discovery alternative waiting to 
be implemented.

For my own environment I will be adopting ipv6 , the global address space and 
autoconfiguration solve many problems that users experience with ipv4 today.

I admit the locked down api caused me frustration, but I think it's clear now 
that we need a process for managing api evolution.  

Complexity - The proxy preparation api tries to determine trust after 
downloading untrusted code and deserialization of unverified data.  As gadget 
attacks demonstrate, too little too late at great complexity.  This was an 
attempt to bolt security onto the existing lookup service.

JERI is good, method constraints are good, proxy trust is obsolete.  River's 
current ssl and https JERI endpoints need to be brought up to date as they're 
no longer secure.  I've already done this work externally, it can be donated 
when appropriate for the project.

If we address security issues, we can provide a secure alternative to RMI  
Oracle has chosen 'whack a mole' security for Serialization, rather than 
address some fundamental design flaws with ObjectInputStream, for this reason, 
authentication of the source must occur prior to accepting serial data.  
Despite common belief, white listing isn't a completely secure solution and 
adds conplexity as it's too fine grained.

For multi language support, this would limit the type system, but then, there's 
a lot that can be done with strings, primitive types and byte arrays.  This 
doesn't have to limit java service types, I think language support should be 
something determined during lookup, so we don't limit the type systems of more 
powerful languages to primitives.

Looking at most Entry's used for lookup, most fields are strings and integers.  
If you look at the way lookup searches are implemented, an entry is represented 
by a string name and each field is a tuple name value pair.

I think a ground up redesign of the lookup service, would address language 
compatibility as well as complexity and security.

In other words, recognise the need for a lookup & registration protocol, as 
well as discovery, after that, the service & client should be able to negotiate 
 whatever rpc protocol they have in common and to do that, we'll also need a 
connection negotiation protocol.  We could write specifications for these 
protocols.  This way we could allow any language/ platform to register and 
provide services.  The code for lookup would not be downloaded as Reggie is 
now, it wo