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 Thu, 14 Oct 2010 13:24:43 GMT

On Oct 14, 2010, at 747AM, Tom Hobbs wrote:

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

Sounds like it should be it's own (sub-)project.

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

Well, I disagree. What better way to enforce and test the use of utilities than having River
itself use them?

>> [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'd suggest that this has already been happening. I'm here am I not? :)

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

With all due respect I think you're missing the point. The issue here is that many of the
things that you wish to accomplish have most likely been done across the myriad of Jini projects
that have been out there for years. The reason these projects have been created is "to make
it easy and obvious to application developers". Historically, the Jini community at large
seems to have a hard time recognizing and endorsing external projects, I dont know why, it
just has. What I am seeing here is an opportunity to leverage the work that has been done
to move River forward in a better way.

Instead of going out and developing utilities, you could provide a list of capabilities (perhaps
creating a call for action), and those that would be inclined to contribute can. Alternatively,
you may also be pointed to open source projects that allow you to build upon (or leverage/learn)
what has already been done. Consider this includes things like:

Configuration utilities and approaches
Maven archetypes (and support in general)
Smart proxy approaches
Annotations for Jini services
IoC for services you require
(others ...)



> Which is the same
> disservice to River that River ignoring those same external projects
> would be to them.

View raw message