river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject What is River?
Date Fri, 15 Oct 2010 11:17:29 GMT
I've been having a chat about what various things in the "Extras (was
PGP)" thread and something has come up that I think requires a new

What *is* River?

Some of the work in "Extras" that I want to do is make is easy for
developers to get started writing and using River services.
Paraphrasing some of the comments on tha; "there's plenty of
containers and third party applications around, users should just be
pointed towards them.  We should be concentrating on making it easy
for users to swap between these containers, rather than reproducing
anything that they do".

Please correct me if that paraphrasing is unfair/wrong.

So my question is this; do people see River as existing solely to
provide functionality to the third party containers, thereby meaning
that developers should only ever be downloading River as a dependency
for their chosen container/application; or do we see developers
downloading and using River directly?

My personal view is *both*.

In my experience, I've worked on a project that was implemented
without any third party container, directly using the River (or rather
Jini 2.1) code-base.  I admit that we ended up writing a
container-like service in the end.  We certainly never downloaded or
used any of the existing containers, in fact I'd never heard of them
until I started getting involved in River.  My work on that project
would have been much more simple if the River/Jini download had come
with a few more examples and utilities - or if more noise existed on
the River site about all the third-party applications available!

Reading the comments written by others who use/own/write service
containers, it seems like a lot of work could be done in River to make
their jobs easier.  There's certainly a lot of information and ideas
that can flow both ways.

So is there room for both approaches?  I certainly have the will to
try and work on both, I'm reluctant to reduce the "make using River
directly easier" component to being fulfilled by just supplying a list
of external links to other software products - although such a list
would be a desirable addition.



View raw message