Vladimir Nadvornik wrote:
::snip? SNIP!::
> - If we want to make everything configurable, it might be a good idea to
> use XML for config file, because the current format is not optimal
> for re-using components with different configuration (for example
> the configuration is saved only for the first layout window).
> It should not cause much overhead, XML parset is in Glib, and
> writting via secure_fprintf is easy.
I'd just like to voice my disagreement: XML sucks. In particular, it's a pain
for humans to edit, it can be a pain for humans to read, it's
computationally-intensive to parse, it's hard to parse, and it's even harder
(if
not impossible, with most parsers) to only parse a section of a document — if
you want to have a layout config and other configs, you end up with multiple
config files, or having to construct the entire DOM in memory every time you
want to make or pick up a change.
An alternative that would be easy to read, easy to edit, easy to parse, and
easy
to parse partially would be just to have blocks that contain objects. Each
block has delimiters "Foo" and "EndFoo". An object is "Bar(...)" where the
ellipsized stuff needs to be on a single line.
Non-object key-value pairs would be just things separated by a colon or
equal-sign, similar to geeqierc right now. You just wouldn't have to use the
namespace as part of the name. And if you stipulate that any block cannot
contain other blocks with the same name, voila: you can parse it with a regex.
This:
> <layout>
> <sidebar>
> <InfoPane title="Basic Exif">
> <InfoEntry title="Lens" key="formatted.lens" />
> <InfoEntry title="ISO" key="formatted.lens" />
> </InfoPane>
> <Histogram channel="R"/>
> <Histogram channel="G"/>
> <Histogram channel="B"/>
> </sidebar>
> </layout>
> <global>
> ...
> </global>
Would become:
"""
Layout
Sidebar
InfoPane(title="Basic Exif")
InfoEntry(title="Lens", key="formatted.lens")
InfoEntry(title="ISO", key="formatted.ISO")
EndInfoPane
# this is a mild-mannered comment
Histogram(channel="R")
Histogram(channel="G")
Histogram(channel="B")
EndSidebar
EndLayout
Global
...
EndGlobal
"""
This looks very similar to the XML above because that example is simple, pretty
XML. Keep in mind that compliant XML parsers are guaranteed to be able to
parse
the following, too:
<layout><sidebar><!-- don't mind me </layout> </sidebar> no parse error here
--><
InfoPane title="Basic Exif"><InfoEntry
title="Lens"
key="formatted.lens" random="I feel like thinking about the meaning of life"
><InfoEntry title="ISO"
key="formatted.ISO"
></InfoPane><sidebar><sidebar><sidebar></sidebar></sidebar></sidebar><Histogram
channel="R" /><Histogram channel="G" /><Histogram channel="B"
/></sidebar></layout><global>...</global>
Now, my point isn't that anyone would end up with a config file like that, but
rather that nobody in their right minds would — some of those things don't even
make sense for our use case. The flexibility to parse that jumble of XML is a
big part of what makes XML parsers so complicated and inefficient.
So, by coming up with our own format, we keep what flexibility we need and get
rid of the extraneous flexibility that XML allows but that isn't useful for us.
As a result, we get a format that's _guaranteed_ to be trivial for humans to
read, trivial for humans to write, cheap to parse, simple to parse, trivial to
update, trivial to modify... there's almost no comparison.
And, for instance, if it becomes apparent later on that we need to be able to
handle Object definitions that span multiple lines: just update the parser and
it's magically backward-compatible.
--xsdg
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
