Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <3F7EF637.3020805@apache.org>
Date: Sat, 04 Oct 2003 18:32:55 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Avalon Developers List <dev@avalon.apache.org>
Subject: Re: [RT] avalon (merlin) == safe == programmer effort
References: <HM8KZO$IgznIZTVmM57vHwZ0oJkL1tzu0NEyhote0b@uol.com.br>
 <blmnev$307$1@sea.gmane.org>
In-Reply-To: <blmnev$307$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Leo Simons wrote:

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

Is this really the case?  If a container does not provide the clean, 
safe, sound and understandable context then your simply transferring the 
responsibility to the component implementation to clean-up its act, 
practice safe sex, demonstrate soundness of judgement, while maintaining 
understandable code. 

Given a scenario of one container, 1,000 component developers, and a 
conservative 20 components per developer ... now let's imaging that each 
developer writes 10 amazingly efficient lines of code in order to 
facilitate responsible component semantics relative to the safe-sex 
viewpoint.  This means that we have a total 10x20x1000 lines of code 
dealing with safe-sex from a number of different positions.  That's 
200,000 lines of code - and we only dealing with one viewpoint! 

The alternative is to push safe-sex handling over to the container.  
Let's assume that a container deals with this with perhaps 200 lines of 
code (taking into account a broad spectrum of positional variations). 
What we have is three order of magnitude improvement in the efficiency 
and maintainability relative to the problems space.

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


Just so I understand the arguments here ... what you saying is that we 
have this dirty little unsafe container.  And, the principal redeeming 
quality is the attribute of an absence of thought - woops, sorry - effort. 

Ok, I'm hooked, let's go with the flow ;-)

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


BZZZZT (private joke)

Doesn't work in a COP scenario.  You don't know in what context your 
component will be deployed - and without some notion of "quality of 
environment", your strategy destroys the potential for component reuse.  
Sure, if you have a bunch of dirty little components with all of the 
benefits of street-smart wits, running in a dirty little container, 
sure, you have economies of scale.  On the other-hand, maybe I'm missing 
the point ... but ... could you explain to me again why this is a good 
thing?

:-)

Cheers, Steve.

(a dirty little developer brought up in a dirty big container)

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org


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