Hi Dennis,
Good to hear from you.
The truth is, I'm no build expert, Dan is much more capable than I am,
so I'm waiting to hear Dan's opinion on Gradle, it certainly looks good.
Would you be interested in helping to create a Gradle build?
Something else I've been thinking about is you once proposed to
integrate Rio with River, by the time I saw the proposal it had
unfortunately already been shot down. I was wondering if you were
still interested in doing that? If so, what do others on the list
think about it?
I think these are good suggestions, but we'll need some help with
presentation and communication. I'm low level infrastructure focused,
not so much at the application level.
River's potential future strong points with IPv6 will be secure end to
end dynamic discovery. The tide seems to be turning for dynamic code,
which was both a strength and an Achilles heel, is now looking a lot
less like an Achillies heel and more like a strength again as originally
envisioned. Unfortunately today Android and Apple iOS and not really
supportable as Jini clients, so I have doubts about consumer IOT, I
think we might be better suited to industrial IoT, time will tell. We
will have the only pure Java Object based remote invocation framework
that can integrate properly with OSGi, when support for it is added. I
think we've had much longer to understand problems with distributed
computing and are overcoming them now.
I'll reply some more later, given time to think some more...
Regards,
Peter.
On 5/22/2020 3:20 AM, Dennis Reedy wrote:
I think showing/explaing how River can fit into a larger eco-system of
existing applications would certainly help. How could River augment Spring
Boot? What would it look like to combine River and Kafka? A discussion of
what it would mean to deploy micro-services built with RIver in the cloud?
What are the set of problems that River solves in 2020 that are not
solvable by other technologies? Is this about IoT? If so then the project
page should reflect that.
As far as the modular build is concerned, sure it may help, but if it is
done, lets please use Gradle. A few years ago I put this example
<https://github.com/dreedyman/apache-river-example> together, it may help
with that.
On Thu, May 21, 2020 at 9:54 AM Bryan Thompson <br...@blazegraph.com> wrote:
I think engagement requires a few things. +1 on the technical points that
you have called out Peter. But we also need to engage developers beyond
those who are traditional users of River/Jini to foster new development
with River. Which can then lead to new development of River by a broader
base of developers.
The modular build can definitely help create opportunities for developers
to get engaged. But having examples of what they can achieve and how easily
using modern security and IPV6 Is important for there to be any new
developers using River.
My question would be where are we on that roadmap. I know that we have been
making progress towards this. When will the project reach a state where it
will engage a new group of developers and what actions will it take to help
make that happen beyond the technology development?
Bryan
On Thu, May 21, 2020 at 01:46 Peter Firmstone <peter.firmst...@zeus.net.au
wrote:
Thanks Patricia,
I'm not sure we're going to see a significant number of developers
contributing in the near future.
Unfortunately the technical matters, which are complex and difficult
have caused a lot of argument in the past and have been the cause of a
high barrier to entry for new developers. At least that's what I
think, feel free to provide your perspective.
I have been working on solutions to address some of the complexity.
I noticed that the board thought we hadn't had any commits for 3+ years,
I'll be sure to add some commit statistics to the next board report. I
counted 191 commits over the last three years, not big, but not nothing
either.
I think it's fair to say that we need Apache's infrastructure, our web
site, Jira bug reporting system, repository and mailing lists.
The old 2.2 series code suffered from fragility due to race conditions
and other bugs, understandably this made some existing developers very
fearful of change (who had probably suffered from this fragility in the
past) and the pace at which development was occurring had some
frightened, which impacted our ability to work on the code, for this
reason I don't talk too much about the code, as I fear the return of
arguments of old, you might say I'm a bit shy. In fact I am hoping
that slowing down the pace of development as was requested has given
people time to accept and adapt to the 3.0 release series.
I have been pinning my hopes on the Modular build to allow new
developers to focus on smaller components without having to understand
the whole project.
Also I think that River is constrained by the limitations of IPv4, I
mean who only codes for the intranet these days? Once we integrate
multicast IPv6 support (I have been using this for at least two years
now), we can communicate easily over the internet.
Another concern I have is security, we should have fixed security issues
a long time ago, however the mood of development at the time didn't
foster that, I think it was 2010 when I first flagged security issues
with Serialization. That's another reason why I've been hesitant to
create bug fix releases, I don't think the code is good enough for a
release without addressing some significant security issues first.
But clearly people are using the security features of River like SSL/
TLS, which indicates people are using River over the internet already,
in spite of limitations with IPv4 NAT. I have other fixes that address
TLS security issues in River and bring cyphers and constraints into
2020, rather than 2004 era cyphers.
Regards,
Peter.
On 5/21/2020 10:54 AM, Patricia Shanahan wrote:
The board tends to be more concerned about an active community than
technical matters. We need to discuss whether there is a pool of
potential contributors who are likely to become active.
On 5/20/2020 5:51 PM, Peter Firmstone wrote:
Hello River Folk,
I've received feedback from the Board this morning, they are
requesting that we discuss the Attic for River.
Personally I think the project still has a lot of potential to pick
up again once the modular build is complete, and it is a useful place
to send patches and discuss changes.
A very important patch was sent in June last year by Shawn Ellis for
Java 11.0.3 and later for services using SSL/TLS.
Another important change to the JERI protocol was discussed in
September last year.
http://mail-archives.apache.org/mod_mbox/river-dev/201909.mbox/browser
What are your thoughts?
I don't think the board is asking that we send River to the attic,
just that we discuss it.
Regards,
Peter.
