[Mulgara-dev] sparql web app config

Gregg Reynolds dev at mobileink.com
Mon Dec 27 17:13:44 UTC 2010


On Thu, Dec 23, 2010 at 1:41 PM, Paul Gearon <gearon at ieee.org> wrote:

> Hi Gregg,
> > While I'm at it:  the config stuff in Mulgara is pretty complicated.
>  Castor
> > (and XML in general for simple tasks) seems like overkill;
>
> I disagree with this. XML was designed for all levels of
> configuration.


OK.  Matter of taste, I suppose, and if it ain't broke don't fix it.
 Nevertheless, for the sake of clarity I'll explain my thinking.

Minor point:  XML is certainly used for all kinds of data, but it was
designed for documents, to address the shortcomings of SGML.  It was only
when its superiority for that purpose became clear that people realized it
could be used for basically any data and started using it for all kinds of
purposes, often inappropriately.  Backlash started emerging a few years ago,
even for documents; witness the popularity of various plaintext formats like
markdown, yaml, etc.

Whether XML is good for basic application config files is debatable; where
it is definitely abused (IMO) is as a
scripting-language-with-pointy-brackets.  The success of XSL
notwithstanding.  Jetty provides a good example.  The xml config language is
essentially a java scripting language with XML syntax.  It would be far
better to either use a real scripting language or design a human-friendly
DSL using e.g. Antlr.


> Also, it's not like we had to bring an XML parser in
> just for configuration, since it's already needed for several other
> things (most notably, RDF/XML).
>

Doesn't castor involve schema validation too?  YMMV, but for my money XML
Schema validation for simple configuration data is definitely overkill.


> > wouldn't it be
> > simpler to just use simple property files?  Or something specialized for
> > configuration, like JFig?
>
> I believe Castor was chosen to avoid having to deal with XML parsing.
> I think someone might have liked the idea of multiple storage options
> as well (not just XML).
>
> Personally, I don't mind it. It shows up as a class with lots of
> properties, each of which indicates a configuration option. It's quite
> easy to use, and no code was needed to set it up. Note that by using
> XML it is possible to create nested structure in the XML. This isn't
> used extensively, but it IS used, and it would be hard to configure
> with a simpler config system (e.g. properties files). For instance,
> the various factories can all have properties associated with them.
> This isn't used heavily in the default configuration (there's just a
> "dir" attribute), but some factories allow for a lot more
> configuration to go on.
>

Log4j is a good example of how hierarchy can be supported in simple property
files.  A bigger problem is where we have multiple entries with the same
tag, e.g. ContentHandler and ResolverFactory in the mulgara config file.
 But I guess that could be handled by writing a comma-separated value list
for one property name.

I see two drawbacks to using castor for XML config stuff.  One is the
learning curve.  It may be easy to use once it's all set up, but if I want
to enhance the config stuff I have to learn not only castor but XSD, instead
of just adding a property.

The major drawback is not XML but that castor isn't designed for
configuration.  What makes packages like JFig
<http://jfig.sourceforge.net/>attractive is built-in support for
hierarchies of config files.  It would be
nice, especially during development, to have something like ./mulgararc >
~/.mulgararc > /usr/local/etc/mulgararc > MULGARA_HOME/mulgararc

By the way, don't get me wrong, none of this my postings are intended as
"Paul's Tasklist".  It's mostly stuff that I'm thinking of doing just for
fun.

-gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20101227/cdc1b0c8/attachment.html>


More information about the Mulgara-dev mailing list