avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexis Agahi <a...@users.sf.net>
Subject Re: [RT] avalon (merlin) == safe == programmer effort
Date Sun, 05 Oct 2003 12:33:15 GMT
On Sunday 05 October 2003 13:32, Leo Simons wrote:

> The point is in seeing that back when we all (as IT community) chose
> XML, it was in some places a very bad choice :D

sure, XML is not designed for programatic stuffs (well maybe it depends on our 
background, because I've seen incredible XSLT programming stuff, done by 
people who had never seen anything like java).

> I'm not saying avalon's XML configuration mechanism should go. That
> would horrify everyone. I'm saying that, if you feel like replacing the
> de-facto standard of using XML with anything else (like the Jini 2.0
> config format we started this topic with), a scripting language like
> BeanShell or ruby is a better choice than anything else.

Ok, why not. 
But sometime more choice equals more confusion. It is currently a bit hard to 
explain the configuration IoC principle to devlopper, if you add scripting, 
this could drive them to confusion and heterogeneity.

But I aggree that for quick dev/test phase this could help.

> But you'll have a hard time finding a seasoned sysop who prefers XML
> configuration to the Apache HTTPD config file (which is basically a
> custom scripting language), or the Samba one.

It depends.
If you consider "old style *nu|ix sysop" you are probably right.

> Its easy to find a java programmer who prefers an XML config file to a
> scripted one. But I just think all those people are being silly and I'm
> not :D

ok ;)

> > (even javascript is far from java).
> indeed. BeanShell has full support for java syntax. You could have java
> programmers write configurations in java (as per the examples I gave).
> You could have sysops write configurations in python or ruby.

yeahh. in your dreams ;) Most of the sysop (I'm not talking about sysop/hacker 
profile) just want the application to run without having anything to do or 
configure. Just take a look at how many IIS are running with default conf, to 
see what I mean.
But ok, this does not mean that we should close all the doors.

> > Also XML is now well known for most of the sysop,
> I think its well-known to sysops who manage java applications. Outside
> that subset, I suspect most sysops don't know xml that well.

I'm not so sure.

> > XML config files are human readable,
> excuse me? Human-readable?
> http://cvs.apache.org/viewcvs.cgi/avalon/buildsystem/maven-common.xml?rev=1

lol, ok.
easy shot. Do you want me to write you an url of unreadable sendmail config 

> barely. If I were to show my non-programmer flatmates your average
> tomcat config file as compared to your average apache httpd config file,
> I doubt any of them would go for the former.

The fact is that most of good programmers with the help of good frameworks 
(;)) use to externalize *all* static value in config file. So this drives you 
to huge conf file with 99% of value that you will never touch in most of the 
time (take a look at jboss config).
For that, Merlin offers a good solution based on "defaut" .xconfig files for 
each component, and help to reduce the main conf file (an increase 

This is not a common practice in C/C++ *traditionnal* programming approch 
(even if I guess that it is now more the case).

> in summary:
>    "XML combines all the inefficiency of text-based formats with most of
>    the unreadability of binary formats." -- Oren Tirosh, comp.lang.python

XML is just a self describing hierachical text format.

>  > What could be done is having "Scriptable" components (such as
>  > Initializable, or Configurable) that could be scripted during
>  > component lifecycle.
> Hmmm. What would that interface look like? Something like:

>    public interface Scriptable {}
> well, maybe a metadata tag would work better:
>    /** @@Scriptable */
>    public class MyBlah { /* ... */ }
> but, this metadata is also available by virtue of the script file being
> available. So strip that, too, and implement some simple logic like:
>    if <<scriptfile exists for class>>		// pseudocode
>      try
>        <<initialize using scriptfile>>
>      catch
>        <<issue warning>>
>        <<initialize using avalon-framework>>
>    else
>      <<initialize using avalon-framework>>
> This, of course, leads to a lot of logic implemented in the container
> which is inflexible (if/elseif/elseif/else considered harmful). The fix
> is obvious: allow for a ComponentFactory/ComponentAdapter idiom (like
> fortress has, as does PicoContainer) and get more flexibility:
>    factory = factories.select( class )		// pseudocode
>    return factory.instance()
>    class ScriptingFactory
>      instance() return <<initialize using scriptfile>>
>    class AvalonFactory
>      instance() return <<initialize using avalon-framework>>
>    class PolicyFactory
>      instance()
>        try
>          return <<delegate to ScriptingFactory>>
>        catch
>          return <<delegate to AvalonFactory>>

As you wish. :)

All I've to say is that "scriptable" features could be nice (even if I'm not 
really 100% convinced) for some applications, and could be availble as 
lifecycle stage of the component.

> Implementation in merlin
> ------------------------
> I looked at that some time ago, and it is simply too much of a hassle.
> Merlin in its current form is simply not built with this kind of
> extensibility in mind. Which leads to the conclusion that, for the near
> future, probably no avalon container will be scriptable :D

ouch ;)
it is time to join the forces ;)

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

View raw message