river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: Extras (Was: PGP)
Date Tue, 12 Oct 2010 15:55:22 GMT
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 <tvhobbs@googlemail.com> 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?  ;-)

Mime
View raw message