Sim has just reminded me of something I meant to bring up earlier. > Giving some thought to a remark one of the mentors made, we are discussing > all kinds of nice features, > but we are nowhere nearer to convincing others to use river for their > projects.
The way I've described River in the past has been as Lego bricks. To my mind, River is the very small Lego bricks; the ones that you can use to build absolutely anything you want. In my opinion, (and also in my experience), Application Developers don't want very small Lego bricks. They want door pieces, hinges, long bits, Lego motors and little Lego monkeys. River certainly doesn't supply any of those, if you want a hinge, then you can use the little bricks to make one and everyone has to make their own hinges. I hope I'm not going to get flamed for saying that a River distribution should include some pre-built (lego) assemblies. Probably in a separate JAR(s). A while back, Sim and I can up with the idea of having an "extras" package (or entirely new source directory) for such things to go in. I've made a start with a self-healing proxy in a skunk branch - it just needs documentation now. I've got a few other ideas of things to put in here and of course more ideas/contributions are always welcome. Convincing people to use something is always easier if you can give them free stuff. While it's true that you get a *lot* of really good free stuff with River/Jini, it tends to be lower level, i.e. not Application Level, stuff. When starting out with River/Jini, because there is so much going on, it can be difficult to see the wood for the trees. I think working on some of this "extras" stuff (and documentation, tutorials etc) might be enough of a sweetener to get other people using it. If we were to vote, I'd put this and bug fixes to be the focus for the next release. But I'm curious to see what other people's opinions are. Cheers, Tom P.S. I'm not saying that it's unimportant or not useful - and this is just my personal opinion/experience; I've never encountered the need to invoke untrusted/unknown services over the Internet. I've only every been involved in projects where any available services could be trusted (they were all on internal subnets, or connected over VPNs etc). Also, as I've recently demonstrated, I'm not a security expert. :-) Jini/River is already very customisable and as such can be an utter headache to start implementing or debug the setup. So of course, these pluggable security bits your guys are designing and discussing are going to be really well documented to make them easy to drop in/pull out as needed. Right? ;-)
