How about denominating these a "library"? Sent from my iPhone
Michael McGrady Principal investigator AF081_028 SBIR Chief Architect Topia Technology, Inc Work 1.253.572.9712 Cel 1.253.720.3365 On Oct 12, 2010, at 8:24 AM, Tom Hobbs <[email protected]> wrote: > 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? ;-)
