"We can't lose XML!" --------------------
Alexis Agahi wrote:
I dont think having scripting configuration should override current XML config model.
indeed. You point out how XML has been ingrained into daily life of programmer and sysop. Its neither straightforward nor desirable to move away from XML.
<disclaimer>I'm not sure to understand exactly your point</disclaimer>
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
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.
For the sake of argument... --------------------------- Just for fun, let me play advocate of the devil some more....
Having script means knowing another language
that all depends on what "another language", and to "whom" it will be "another". You are right, of course, that many programmers and sysops know XML.
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.
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
(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.
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.
and proposing them "exotic" config file could fear them.
indeed. However, providing the choice of a format that is otherwise quite a bit more familiar to them (RPM, for example, uses python scripts for configuration) than xml might give some interesting results :D
Also, I place much more trust in sysops
XML config files are human readable,
excuse me? Human-readable?
http://cvs.apache.org/viewcvs.cgi/avalon/buildsystem/maven-common.xml?rev=1.9&content-type=text/vnd.viewcvs-markup
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.
and application friendly (I mean you could have for exemple a main application that could generate XML config for all your running apps).
This is a /really/ great feature of XML. Had XML not bean machine-readable, it would have never gotten anywhere. It requires about a megabyte of jar files and a complex and heavy beast called xerces (roughly as complex as, say, GCC) to implement, but yes, it can be parsed by machines.
Scripting languages like python and ruby go *way* further than that though. They provide built-in serialization/deserialization of any object.
Go further with something like YAML [1], and you can serialize/deserialize just about any object into a format that is way more human-readable than the most beautiful XML.
in summary: "XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats." -- Oren Tirosh, comp.lang.python
Implementation in a container ----------------------------- > 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>>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
cheers!
- Leo
[1] - http://www.yaml.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
