river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Extras (Was: PGP)
Date Wed, 13 Oct 2010 15:47:44 GMT
With the JSK landscape as populated as it is right now with services and utilities, I would
suggest that as part of an upcoming release the project starts to breakout the JSK into platform,
services and utilities [1] first, before adding additional code.

Consider now we have

Infrastructure/Platform:
Discovery & Join, Lookup, Leasing, Transactions, Distributed Security, Events

Services:
Outrigger, Reggie, Mercury, Mahalo, Fiddler, Norm

I would suggest that Reggie be added to the platform, and the rest of the services be put
into a services subproject (or module) and allowed to move on their way. Adding utilities
at this point seems to be a one-off, and none of the services actually use the utilities (eating
your own dog food).

Dennis

[1] Lets not also forget that there are plenty of utilities available with external project
like Rio, Seven, etc... IMO, failure to look at these as providing utility to the project
will be a disservice to the community at large.

On Oct 12, 2010, at 1124AM, Tom Hobbs 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