river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Ramsdale" <jeff.ramsd...@gmail.com>
Subject Re: Future of Jini/River
Date Wed, 12 Nov 2008 06:57:35 GMT
I'd like to reword Gregg's user experience goal and make it a mantra
for further Apache River development, with apologies to those who've
said it before: "easy things should be easy; hard things should be

Now I've raised this point at past Jini community meetings and the
feeling I got from core community members was that distributed
applications were by definition hard and thus only REAL software
engineers who paid their dues had any right to use Jini. That's
rubbish. Everybody and their mother is doing cloud computing this and
multi-core that and virtualized messaging infinitely scalable mashups.
People are going to do these things whether they are qualified to or
not. The question is are they going to use Apache River. Right now the
answer is no, though we all know it should be yes.

The other feeling I've gotten from past community meetings is that
Jini/River has no cohesive vision. That is, some people think Jini
(since the conversations were pre-River I'm going to say Jini here) is
a toolkit for building distributed applications and others think it is
a toolkit for building distributed application frameworks. Well which
is it? Who is the Jini audience? Are we meeting their need? In any
case, is there a roadmap? (Answer:

I'm with Niclas--I agree with pretty much everything he said in his
initial post, which echoes Tom Hobbs from the "River-261, namespace
change" thread.

I appreciate Gregg and his work but feel the first steps have to be
baby steps. Let's make the code easy to get, easy to build, easy to
use. Let's post nightly builds. Let's add something to the roadmap
(like maybe a release schedule? And then plan on regular releases...).
Let's ask each of the service container providers (Rio, Seven, etc.)
and the community what their top 3 feature requests are and find the
low-hanging fruit (InputStreams!).

If I can add a second mantra, and this was also mentioned previously:
release early, release often. That's how you bail faster than you
sink. Without a fluid release process there's no way Gregg or Sam or
anyone else can get their contributions even considered and it's
perfectly clear that Apache River will not survive solely on committer
contributions. Please pardon the aquatic references...


On Tue, Nov 11, 2008 at 9:53 PM, David Zaffery <zaffman@gmail.com> wrote:
> Gregg, everyone...
> You're last comment cuts to the chase of what River needs to move forward,
> with more acceptance and participation from the community.
>> /I think we have to focus on the user experience and wrap a lot of the
>> mechanics into simple wrappers that don't remove access to the details, but
>> just provide reasonable defaults./
> While Jini/River is amazingly great, unless the experience of using it is
> _/drastically improved /_it will never gain momentum and die in incubation.
>  The Rails & Grails community follow the code-by-convention paradigm, and
> their acceptance has been very rapid.  If all of us who are interested in
> River want it to succeed, then it needs to be made painless to start and use
> just as the Rails/Grails crowd as done.  The Servlet versus EJB is another
> example where simple wins the race.  Servlets are easy to code, EJBs are
> /perceived/ as not easy...which one is more prevelant today?
> I want to be able to use River, but I honestly can't take the chance on
> incorporating in an Enterprise unless there is a community to support it.
>  So why not start with Gregg's ideas and roll them in.  Focus on the user
> experience make it great.  Then River will have something to talk about, and
> could be pushed on InfoQ, TSS, etc....
> - Dave Zaffery

View raw message