river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Loubser <da...@travellinck.com>
Subject Re: River future direction
Date Wed, 01 Apr 2015 15:13:23 GMT
This is an interesting topic, probably with very widely-ranging views
from the community members.

River enables strongly-typed, ad-hoc distributed networks of services.
Strong typing, and real, compiler-checked services contracts are superb,
and offer distinct advantages over River's competing technologies.

Come to think of it - I'd be interested in a discussion over what
exactly River's competitors are?

Both Java as a whole, and Jini/River, has received a bad rap for "bloat"
and "complexity" - and if we can change that perception (and realite,
where needed), all that remains to be asked, is this: What is the
compelling use-case for this technology?

I think we all scoff at this "internet of things" bandwagon, knowing
that Jini provided an infrastructure for this 16+ years ago. In all that
time, however - what has happened? Is now the time?

River has to convince the world about the strengths of this model. It
has to illustrate why code downloading is desirable, and make it easy to
do, and appreciate.

I have to feel that the real use-case is that which it always has been -
small, embedded devices, and smart phones. True peer-to-peer discovery
and interaction, something being tackled from another angle by projects
like ZeroMQ's Project Hydra <https://github.com/innotech/hydra>.

I feel that I would enjoy something like programming my Raspberry Pi
much more, if I could interact with an ever-growing set of clean service
interfaces representing the capabilities of my own device, and other
devices around it on the network, without manually having to wire things
together using all sorts of painful low-level APIs and mix-and-match

River should make the "internet of things" come alive, demonstrating a
higher-level understanding of how to describe, and interact with,
services. It should be fun, and obvious.
//Ironically, we use River in the enterprise space (not in the embedded
space), but all the River technicalities are largely hidden by the Rio
Project for us. We are using it for the purposes of JavaSpaces, upon
which I've built a flow-based programming -like framework, for
long-running, reliable, flexible processes./

kind regards,

On 01/04/2015 16:40, Patricia Shanahan wrote:
> I would like to start a discussion of future direction for the River
> project, and whether we have the right resources to get there.
> Recently, I have been trying to push improving the "Getting Started"
> experience in the hope of attracting and keeping new users who may
> turn into committers. I am not sure what to do next to make that
> happen. I feel we may have a problem of not having enough committer
> time to get more committers.
> I do have some free time, but not quite the right skills. When I got
> involved in River I expected to be working on Java programming for
> refactoring, performance enhancement, and multithread/multiprocessor
> issues. Writing good "Getting Started" materials calls for actual
> River expertise and experience, which I lack.
> I have about five weeks before I need to file my next board report. I
> would like to use that time to build a consensus on where we are
> going, and whether we need help from outside the project.
> Patricia

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