Wrapping scripts in XML, was: Separating internal errors from addressing errors in config.xml

["Richard O. Hammer" <RO...@EarthLink.net>]

Vincenzo Gianferrari Pini wrote:
> Thinking more about it, the key point is perhaps that while the (IMHO) very nice java exception mechanism, with the "throws" declaration enforced at compile time, allows for a good coding practice of having each level in the call stack manage its pertinent exceptions appropriately and deciding whether to continue or not, in the matcher/mailet stack there is a level that never gets involved, and therefore can not manage its pertinent exceptions: "the config.xml logic"!

This reminds me of one of my pet peeves, the current tendency to wrap 
the instructions of a scripting language in XML.  I believe that XML 
is good for some uses, but that it is also being used now in many 
places where something else would be better.

For example, the James config.xml file contains a mixture of what I 
would call configuration data and scripting instructions.  This 
element contains what I would call configuration data:

       <postmaster>Postmaster@localhost</postmaster>

Whereas this element contains what I would call an if-then instruction 
in a scripting language:

       <mailet match="All" class="ToProcessor">
          <processor> transport </processor>
       </mailet>

Now I must caution you not to listen to me too much, or to take me too 
seriously, because I might be wrong.  I am still a newcomer to 
Internet programming, or perhaps more of a Rip van Winkle, since I did 
a lot of CS work 1977-1986, but then went away and did other things 
until Y2K, when I returned to a programming world which had changed. 
Most of the dominant features (Windows, www, objects, Java, XML) were 
totally new.

Seeing that I have only a few years experience in this new world, I 
still have not faced first hand the problems which have driven many 
modern developers to wrap their scripting instructions in XML, so 
probably there is some light that I will see when those problems hit 
me over the head.  But until that time all I can do is talk about it 
academically.

It strikes me that the principal content of the spoolmanager block in 
the config.xml file is in fact a computer program.  It is a script in 
a scripting language which is interpreted by James.

If I am correct about this it seems to me that the users of James 
would find it more understandable if the developers of James (and Ant 
too by the way):

1) acknowledged that they were writing an interpreter of a scripting 
language

2) consciously wrote down the scripting language, its syntax and semantics

3) discarded the XML envelope which only obfuscates the instructions 
of the scripting language

I think if-then instructions are easier for poor befuddled brains like 
mine to grasp than things like this:

       <mailet match="All" class="ToProcessor">
          <processor> transport </processor>
       </mailet>

Well, this is all kind of theoretical.  It can't have any short term 
impact.  If you are busy today it would probably be best for you to 
skip reading this message and get on with your important work.

Rich Hammer


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