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 Thu, 14 Oct 2010 11:47:47 GMT
I think that splitting the platform/services apart and allowing each
to mature separately is a good idea and one we should do - in fact I
think that there's been a fair bit of recent discussion about what the
build artifacts should be.

> Adding utilities at this point seems to be a one-off

I disagree with this bit, because I envisage these "extras" to always
increasing and maturing as new features arrive in the River code base.
 Certainly, there'll be a large one-off chunk of activity to write a
bunch of the first ones

> and none of the services actually use the utilities (eating your own dog food).

Yes, I agree that the services do not use these utilities, but that's
missing the point.  In my view, these utilities should *not* be used
by the services anyway.  The ones that I've got in mind sit above the
services and (will) provide easy and convenient ways to allow
Application Developers (AD) to quickly _use_ those services.  Sorry if
I didn't make that more clear.

> [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.

I agree again here, but again with a caveat.  I would like to see a
lot more chatter going on between as many of those external projects
and River as possible.  I think a possible reason for the lack of
chatter has been the recent comparative lack of activity on River's
part (and I shoulder my share of the blame for that).  Now that River
is starting to gather momentum again, it'd be good if we could put our
collective heads together a bit more.

Having said that, what I'd like to do with these Extras is to allow an
AD to download River and have a Jar and/or cookbook which they can
easily read to get them going.  As it stands, justing writing a "Hello
World" service is not documented on the River site or made easy - and
it should be.  I don't want to take anything away from all the
fabulous external projects built on top of River/Jini, but as a AD
myself, I don't want to have to download River and then be told that I
need to make another decision about which external project I need to
download next in order to write effective River services.  Then I need
to learn how to knit the two together.

What I'd like to see (on the River site and what Sim and I seem to be
trying to work towards) is having some documentation that says, "If
you want to do common use case ABC; look in the extras.jar for class
DEF and use it in the following way."  This will get users started
learning how River works, without frustrating them by only supplying
them with the Jini specs and expecting them to just get on with it.  I
have no qualms about adding additional text to each recipe in the cook
book saying "... and if you want to do it properly, or in way that has
these additional benefits, then consider downloading project XYZ".

Actually, if external project authors want to drive people to their
sites, may I cheekily suggest that they write a "How-to" do something
in plain old River, a How-To do that thing better in their project,
and then donate the first half of that document to the River site?

If my goal of "make it easy and obvious to application developers" can
be met with no extra code and just documentation and links to external
projects, then great.  In my opinion though, this appears to imply the
assertion "if you want to do anything useful in River then you need to
download an additional external project".  Which is the same
disservice to River that River ignoring those same external projects
would be to them.



On Wed, Oct 13, 2010 at 4:47 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
> 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?  ;-)

View raw message