On Fri, Jul 26, 2013 at 08:14:56PM +0200, Daniel wrote:
> I think it would be convenient if abook would skip spaces and tabs
> around the = equal sign when parsing the database. This makes the
> database format conform to for example Python's configobj format.
Could you please elaborate on what are you trying to achieve ?
abook format already _conforms_ to the "ini" config file format, eg:
$ python -c 'import configobj; \
config = configobj.ConfigObj(".abook/addressbook"); \
print config["0"]["name"]'
> bla foo
If you mean that abook can *not* read a configuration file as written by
the default behavior of configobj, then this is not really an "issue".
Abook produces a (somehow) valid ini file, but its parser aims to stays
simple rather than exhaustive.
As you probably noticed, abook does not currently use a "standard"
ini-file parser. Just a simple 50 lines function.
As such there are probably more than one unsupported idiom (coming too
mind: trailing backslashes and double-quoted values).
I would say that *at the moment* the abook file's format is intended to be:
1) human RO friendly
2) abook RO/RW friendly
but supporting a complex, or lax file format is not a priority.
So, to summarize:
1) if you had some (common ?) use-cases in mind, please share here
2) While a 10 more lines seems ok for now, could you please also confirm
that supporting space/tab would be enough to cover most of these common
use-cases without further modification (which would then make
parse_database() needlessly over-complicated over the time) ?
3) is there any reason configobj can't write a configuration file
without (these useless) blanks around the "=" sign ?
I guess that would solve the issue as well isn't ?
(this is what we could expect from an ini-format specific lib)
About the probability (and the pertinence) of values starting with
either a space or a tab (backward compatibility breakage)... I bet it is
low, but still, we need a "good" reason (appealing use-cases) to break
this.
Given that people can use custom fields, the request for supporting
leading blanks in values, if it existed, would seems more legitimate
than python's Configobj support, ... and we probably wouldn't want to
get into parsing quotes pairs either at that moment.
thank you
best regards
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Abook-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/abook-devel
