river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Extras (Was: PGP)
Date Tue, 12 Oct 2010 15:59:34 GMT
I'd prefer to keep them alongside the River distribution, in their own
source tree and/or package.

Would anyone object to the "build distribution" Ant task also building
a "river-extras.jar" which included them.  They can then be easily
used or ignored by all and sundry.

Or is that what you meant by "library"?

What I've got so far is already in the SVN (as a skunk branch), I
wouldn't be happy putting them on the trunk without peer review/input.
 It's lacking documentation at the moment - that's my job for this

On Tue, Oct 12, 2010 at 4:55 PM, Mike McGrady
<mmcgrady@topiatechnology.com> wrote:
> 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?  ;-)

View raw message