First off, I'll note that I'm now less averse to this than I was — it turns out that the parser in GLIB only parses a subset of XML (see [1]), and is consequently (I imagine) faster and simpler than a standard XML parser. That said, I believe my points below still stand.
[1] http://library.gnome.org/devel/glib/stable/glib-Simple-XML-Subset-Parser.html Vladimir Nadvornik wrote: > On pá 13. února 2009, Omari Stephens wrote: >> 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. > > Maybe... > >> In particular, it's a >> pain for humans to edit, it can be a pain for humans to read, > > Writing will be fully controlled by Geeqie and I think that it is possible > to write an XML file that is human-readable. > >> it's >> computationally-intensive to parse, > The configuration file won't be that big. > >> it's hard to parse, > > The parser already exist in glib and it is already in memory because it is > used internally in gtk. I'm not saying that parsers don't already exist and aren't easy to use. My point is that if we come across a bug of some sort, the complexity of the parser may make it time-consuming or difficult to debug. Certainly, GMarkup's simplicity does help us here — it's only 3,000 lines against libxml2's 200,000 (not including the 50,000 lines of test). But it's still 3,000 lines. Also, not having control over the parser means that we'd need to work around or otherwise live with bugs that may exist in the GLIB parser — even if upstream fixes the bugs, we're likely to run into older versions of the libs in which those bugs are still present. >> 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. >> > I don't think that we need this. We need just save state at exit and load > state at startup. One of the things which really frustrated me with gqview, and which is better but not perfect with geeqie, was that I would start another instance and not know what settings it was going to come up with. That is, I'd start an instance, edit some settings without closing it, then start a new window in that instance and I'd pick up the changed settings. Then I'd run a new `gqview` command from the shell and the changes weren't there. I think being able to save every time someone closes the Preferences dialog or changes some other setting is valuable. So, whichever way we end up going, I think it's important that the serializer need not build a full DOM in memory before it spits the thing out to a file. >> 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. >> > > I definitely don't want to write and maintain a parser for a format that > serves the same purpose as XML, especially when XML parser is already > available. The difference is that I could write a parser for this format in ruby in 30 minutes, and in C in a day. That's what the simplicity buys us. And the serializer would be just as simple. Especially, consider that a serializer for this format could just run through the existing config file, adding or updating things as necessary; this method would allow and trivially maintain user-inserted comments. Even if we go with XML, we'd still have to write something that turns the config options into a valid XML document. We could use a similar updating strategy for XML (GMarkup is a stream parser), but because there is less restriction on the organization of the document, and we get no information about that organization, we will undoubtedly end up clobbering the formatting of the comments. Also, I don't know how GMarkup's passthrough thing deals with newlines inside of comments. --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
