As a potential new user to Jini/River I wanted to share my first impressions of this project.
River has great potential, it seems like the solution to many common distributed computing problems. I am excited to potentially be using it in my next project. I have been a fan of Jini/River since I first learned about in 1999. I am glad that Jini did not die and was picked up by a community that is full of professionals who are genuinely interested in moving this project forward. All that being said I am nervous about a few things. The biggest being the lack of a good tutorial, and documentation. I noticed on the old site, jini.org, that there were some basic tutorials and documentation. I am not sure if those tutorials and documentation will work with the newest iteration. The last update on the front page is from January 2008. This at first appearance seems like Apache River is a dying project. I believe Niclas hit the perverbial nail on the head when he said " We need to make River more accessible for non-hardcore Jini users." I am not a hardcore Jini user but would like to learn more about it, use it and then possibly become a "hardcore" user. The only thing I would to add to Nicolas's email is that if the Jini/River community needs to publish and promote. If nobody knows about Jini/River then nobody is going to use it. Other developers need to see how Jini/River can benefit them and make their lives easier. I think it is also important to point that while a conversation is great, it is more important to have actions. On that note I would like to become more involved in this project and help out in any way possible. So anyone please point me in the right direction to get started. Jeremy R. Easton-Marks "être fort pour être utile" On Sun, Nov 9, 2008 at 10:50 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > Taking this on-list, which I perhaps should have done in the first > place. Never-the-less, > > On Mon, Nov 10, 2008 at 12:17 AM, Dan Creswell <[EMAIL PROTECTED]> > wrote: > > > For a long time now, I've been waiting to see a conversation around > > "what next for River". This is something of a good start but.... > > People don't like to work alone and 'against all odds', so I think all > of River's problems are related to a couple of real problems; > > * It is perhaps too complete! Not that many things that is in > desperate need of repairs. > > * Overload of Information and Technology Fracture. We have a million > documents, a couple of sites, dozens of related projects that are > spread out and for a newcomer it is unclear what is essential, useful > vs not initially relevant. It is in fact the total opposite of most > projects at Apache. > > * Corporate Approach to software distribution. You get something that > you install and use, pretty much like a big fat database, application > server or similar. Modern developers, often test driven and agile, are > not fond of "System Requirements" when writing their own software. > "Check out, compile, run tests" is the motto for many, me included. > For Jini, it means it is hard to create other open source projects > that depends on Jini. The downstream users have to do too much to get > going. This is probably my pet peeve at the moment. > > These things are not very concrete. We need to make River more > accessible for non-hardcore Jini users. It must be easy to "see the > light" (samples), "to touch the light" (try yourself) and "follow the > light" (embrace) at a very fundamental level. Jini applications > doesn't live in a vaccuum, the technology must be easier to integrate > into other projects. The hardline view that "we are best and everyone > else should learn from us" ain't gonna cut it. > > My own view is that the following areas are first up for review and > rectification; > > * Build System. It must be a breeze to build and test River itself. > The current split between tests and source code should IMHO be > eliminated, tests should be executed on all builds, and I think we > should break up the sources into modules instead of a single large > src/ dir with everything in it. If people wants to move towards Maven, > I will support that, primarily since it simplifies artifact > consumption for downstream projects. Same thing can however be > achieved with Ant. > > * Right-sizing of the Jini Starter Kit. IMHO, the JSK is a misnomer > unless you intend to write your own Jini implementation of the > Specification services. I think that Apache River could just organize > the whole project better, to get around this problem altogether. I > think we can see a "infrastructure product" separate from the > "developer's tools". > > * Configuration System. Although I like it in principle (after all I > was in the JSR-78 EG where it came to light in the first place), BUT > it needs better adjustment to agile and TDD methodologies. Perhaps it > is only a documentation issue, but I have been faced with using > filesystem files to get things going. InputStreams are the way to go. > > * Security System. Although extremely important in many scenarios, the > impact on developers for Jini is too big, too soon. Needs to soften > that up in the documentation, which currently deals with experts and > novices alike. > > * RMI & JERI, Activatable, Persisten or Transient... Duhhh... Give me > choices that I initially don't care about, and I give you a system > that is booted out from the candidate list. The information around > what each means is overwhelming. I would say that RMI has such > (undeserved IMHO) bad reputation that drop it out of the mainstream, > push JERI as "The Java Binary Communication Layer", and IIRC it is > well suited to have other serialization protocols than std Object > Serialization Streams, which would allow people to experiment, measure > and conclude the true story around serialization (what ever that might > be). So, big tasks in place to make JERI more easily consumable. > > * River/Jini 3.0. I think a healthy community needs lofty goals. At > ApacheCon Europe 2008, Roy Fielding was talking about this for Apache > Web Server. He basically called for "next level" of what is possible, > put up serious ambitions and 'screw compatibility' to get there. I > think River could start flowing if some discussion is created along, > "What's the Next Thing?" and see where that leads us. I can imagine > Clouds, Distributed Storage, Network Graph Navigation/Search, new > "Distributed Worker Model", maybe even standard solutions for load > balancing http traffic. Well, I am sure there is a lot to discuss and > dream about. From those dreams come itches, the itches get scratched, > and so on... > > > All in all, I love Jini, but I think the current situation stinks and > if we (those who care) don't do something really soon, it will be a > blip on the radar of Java history. I can unfortunately NOT be the > driving force behind the technology. First, I lack the know-how > required, and secondly I am tied up in a really large open source > project (http://www.qi4j.org), but where I hope to use Jini/River as a > distribution platform. So I could help out in various areas, just to > make my own situation more bearable (scratch the itch). > > > Cheers > Niclas >
