river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: State of the project
Date Tue, 03 May 2016 10:29:39 GMT
I'd like to look at how blazegraph uses River, look at building modules, one at a time, from
the bottom up, integrating with Rio, is that still an option? Unfortunately when originally
proposed it got shot down before I had a chance to comment.

I'd also like to look at parts of the api that aren't adequately defined, like Leases, yep
an expired lease can be equal to one that hasn't yet?  Yes really.

 I'd like to move to git.

I'd like to remove the proxy trust code, that validates after deserializing untrusted foreign
data & code.  Too complex and way too late.  Don't get me wrong, constraints and secure
endpoints are good, proxy trust isn't.  ProxyTrust was designed to work around the ServiceRegistrar
interface that wasn't designed with security considerations in mind.  Java 8 default methods
allow us to change that.

Could we consider a service registrar that doesn't require code downloads? Other language
support?  What might it look like?

The trunk code as it is can be used as the basis for lts, freeing up our ability to innovate,
which we need to do to survive.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Tom Hobbs <tvhobbs@googlemail.com>
Sent: 03/05/2016 02:50:21 am
To: dev@river.apache.org
Subject: Re: State of the project

I’d sum it up by saying that the project is on life support - but it could pull through.

There’s still a release in the pipeline, which hopefully we can get out pretty soon.  From that point I think we should revisit carrying on as-is, introducing some radical breaking changes or the attic.

> On 2 May 2016, at 11:33, Peter <jini@zeus.net.au> wrote: 
> On 2/05/2016 8:59 AM, Patricia Shanahan wrote: 
>> The next River report to the board is due May 11th. I am supposed to keep the board informed of the state of the community. With that in mind, I would welcome input from anyone with an opinion on the matter.

> Well it's not looking too healthy, although it appears we still have enough pmc members to vote (4 active), we've lost a committer recently, interest in the project is tapering off.

> Most of the code in River is aged between 12 and 18 years old, while the architectural design principles employed are sound, parts of the api are showing their age.

> River is tied to Java and is currently deployed in server back end, private networks.  There may be some hope in IoT, however at present we don't support Android and have limited scope outside of Java.  River is also tied to Java serialization, which has fallen out of favour for newer protocols in recent times.

> Although some steps have been made toward modularising River, the monolothic build is hampering development efforts:

> Modules allow a development campaign to focus on one module, allowing earlier completion, followed by review and release of an updated module.  The large monolothic codebase, prolongs a campain, (eg fixing race conditions) and makes it difficult for other developers to keep up with changes, resulting in generation of our own FUD and makes it difficult to release often.

> On the plus side our suite of tests are quite comprehensive. 
> Regards, 
> Peter. 

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