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
