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:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
