> Outside of getting something called River released and getting the
> standard processes going, I'm interested in seeing a simplification of
> Jini/JavaSpaces. 1. Someone else mentioned this, but forget the
> installer, just unzip / untar (take a look at Tangosol or GridGain - it
> is dirt simple) Yes on Maven, Ivy, etc.
> 2. Configuration - simplify it into a property file or at least provide
> that as the default (again Tangolos/GridGain are different, but they are
> simple to set up)
Properties? Why not some XML? More importantly, why do you consider
this simpler? And do you mean you want everything configured in that
single file or just some set of core things? And what are the core things?
In all honesty, I like the way Configuration Files work and actually
want them to be more expressive, even perhaps go so far as to use some
form of Scripting engine to allow this - especially if we have the
abilitiy to make configurations dynamic and use events to signla when
these configurations have changed thus reducing the need to restart
services to apply configuration changes
In addition I have another sampler question for you:
What about convention over configuration?
Okay I'm going to chip in here on the c-over-c debate, and as it's
very based on JSE 5, it may be of relevance. When I was developing
Glyph the issues of converntion over configuration were very quickly
made apparent to me as Glyph does a lot of code generation. So many of
the glyph utilities make reasonable assumptions about package
suffixes, class names and the like - however these are generated by
apt to these conventions and where it makes practical sense it pushes
these conventions into configuration files such that they may be
configured differently at deployment-time. What I'm realising as I'm
working on Glyph, specifically the new leasing and landlord stuff, is
that preferring one or the other is a bad road to go down. Conventions
rely to much on foresight and at the extreme are, in a sense, a way of
hard coding, whilst too much configuration, lends itself to a system
that is way too dumb to work out how things are set out, and/or
provides a system where the administrator has to configure absolutely
everything. Convention is really a configuration pattern, and can be
used to great effect as long as your able to tailor that convention
through configurations. So really you need a symbiotic relationship
between convention and configuration, not one over the other.
Sorry just from my experience
You can now be returrned to your regular programme
Cheers
--Calum
