river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Ramsdale" <jeff.ramsd...@gmail.com>
Subject Re: Drowning in the River
Date Tue, 06 Feb 2007 20:22:00 GMT
I'm with you, Dan, that we need to be looking at the big picture (as
well as the administrivia).

It was mentioned by Sean in another post that River will appeal to two
kinds of developers--the hard core dev wanting full access to the tool
and the more typical dev who wants the complex bits hidden away. I
agree, and would suggest that River should attempt to be an
exceptional platform for building other tools. Optionally (preferably,
in my mind) it could provide its own toolkit on top of that framework
to prove the API.

As an example, I'd like to see the Configuration mechanism refactored
to be entirely Java-based. Then the current code could be modified to
adapt from the current configuration format to the Java configuration.
The hard-core dev could still have the full power of the runtime
configuration but tool providers would have an easier time providing
alternative implementations (Groovy, XML, etc.). Backwards
compatibility is maintained but new options are opened up.
Configuration is a very visible point of difficulty for new users.


On 2/6/07, Dan Creswell <dan@dcrdev.demon.co.uk> wrote:
> Okay, so do we think that developers will be attracted by fixes to
> PreferredClassLoader or coding styles or debate about rules for checkins
> or a collection of JIRA issues they can look at or.......
> Will they be attracted because Jini is deemed cool, it's accessible,
> there are compelling reasons to use it, there's a strong direction which
> everyone can see benefit from, there are some serious challenges
> outlined that people can contribute to etc?
> Or maybe something else entirely?

View raw message