Ditto. 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. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Tom Hobbs <tvho...@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 <j...@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. >
