river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Lotj - languages other than java
Date Tue, 05 Jul 2016 08:35:35 GMT
Thanks Sim, hold that thought, you never know.

The good thing is, we're talking about these things again, without 
heated argument.

An incompatible branch is fine as long as it doesn't have the same 
namespace as the long term support branch, so both can coexist in the 
same jvm.   Those that wish to support a long term support branch or a 
slow moving branch, could do so without impeding a research / 
experimental branch in a different namespace.

It would allow existing deployments to migrate over a long period of time.

Cheers,

Peter.

On 4/07/2016 11:44 PM, Simon IJskes - QCG wrote:
> 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
>
>
>
>


Mime
View raw message