river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Drowning in the River
Date Tue, 06 Feb 2007 21:38:29 GMT
Hi Jeff:

	Question below...

On Tue, 2007-02-06 at 15:22, Jeff Ramsdale wrote:
> 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.

Could you elaborate on what isn't Java-based about it?  Or are you just
saying that there's a configuration file (not unlike how Spring has a
configuration file, except the format isn't XML)?

> 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

Is there anything preventing someone from writing another implementation
of Configuration as an alternative to ConfigurationFile?  I though Van
Simmons et al had done a Groovy version (haven't looked at it myself,
but I thought I heard that during the Javaposse interview).

> compatibility is maintained but new options are opened up.
> Configuration is a very visible point of difficulty for new users.
> Jeff

Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.

View raw message