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 possible."
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: http://incubator.apache.org/river/roadmap.html) 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... -jeff On Tue, Nov 11, 2008 at 9:53 PM, David Zaffery <[EMAIL PROTECTED]> 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
