avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject [RT] avalon (merlin) == safe == programmer effort (was: Re: Jini 2.0 Configuration Files)
Date Sat, 04 Oct 2003 15:02:53 GMT
hammett wrote:
>> (as opposed to the conceptually very clean avalon-style
>> configuration where a component is allowed to "read" from its
>> configuration, but the configuration itself is passive),
> Biased! Biased! :-p

ROTFL! Me? Nah..... ;)

Seriously, one could only consider it conceptually very clean, don't you 

The avalon picture
- a container is responsible for finding/creating the configuration 
according to preset rules (delegating this responsibility to a 
specialized component of course), usually allowing for various people in 
various roles (end users, assemblers, component writers) to follow 
various contracts to define the configuration,

- a configuration object is then responsible only for existing 
(implementing the Configuration interface)

- a component is responsible for obeying the directives provided to it 
by the container in the form of the configuration it receives (and 
complaining if it doesn't know how).

Clean. Add in some more enforcable rules (like requiring component 
authors to provide a container-verifiable schema for the configuration 
format (like a DTD for XML) and component configurators to follow that 
schema), and, save for bugs, all behaviour is completely deterministic. 
Clean, safe, sound, understandable.

The downside? In practice, especially with java and xml, it means way 
many lines of code to write.

Note: its perfectly possible to write a very dynamic scripted 
avalon-framework container. It just happens to be the case that avalon 
(especially with Merlin) is moving further and further into the sound 
and safe, predictable and verifiable corner. In fact, some people (like 
Steve) assert that a container which is not predictable is a Bad 
Thing(tm). Me, I strongly disagree with that assertion :D

The scripted picture
- a container will look for a configuration script according to preset 
rules and run it according to some more rules

- a configuration script had better exist and follow the rules

- a component is not required to do anything special

You lift some responsibility from the component and from the container 
at the price of requiring the end user to write a sensible configuration 
script or suffer the consequences.

The upside? Every piece in this system is a lot simpler, and usually you 
end up with less lines of code everywhere.

The balance
You have a few axes that are not orthogonal:

	clean       <---------------------------> dirty
	safe        <---------------------------> unsafe
	complex     <---------------------------> simple
	static      <---------------------------> flexible
	much effort <---------------------------> little effort

Sacrifice some conceptual cleanness and predictability and you end up 
with a system that is both simpler and more flexible, and, most 
importantly, requires less typing.

In a banking application, you had better make sure that a 
misconfiguration does not ever result in anything bad happening. I 
wouldn't want scriptable ATMs. In your average web server, its okay if a 
web page decides to topple over every now and then, as long as it is 
easily and quickly fixed.


- Leo

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message