Re: [craft-devel] config lib

[Arne R. <arn...@gm...>]

Hi Martin,

> I've just written my own config lib WConfig for another project of mine and I
> think that it could be very usefully for craft. It is almost as fast as Kris'
> config lib and provides some more features than the config libs in /lib/ and /src/:
> 
> - Gives detailled error messages to stderr when a parsing error occurs with
> exact position in file so that the user can correct errors easily.

That's a nice bonus, but I don't think it's that necessary as it is in 
file formats which are more complex. My src/cfglib.?pp is not that 
strict and raises an error, but tries to parse the rest of the file. If 
you have one "bad" character in your config, the worst case is, that one 
option has a wrong value, but all the other values are correct. That's 
because of the simple format: each entry can stand alone and no option 
is based on another (perhaps they are based on each other in a logical 
way, but at least not from the syntax of the configfile).
I'm not sure if it is better to abort parsing when there is an error or 
if it is even worse than to try to continue in the best possible way. 
For example, if this error message is printed to stderr, a windows user 
won't even know that there is an error in his configuration, as long as 
he does not look into the stderr.txt file. If the program starts normal, 
but does not act as the user putatively told in the configuration, there 
is a good chance that he will look into the file at the exactly right 
line (where he defined the option that is ignored) and find the "bad" 
character.

> - Recognizes some more formats, I think. For example:
>   str = "test test"

Of course, that would be quite nice for all coders, because they 
(normally) are used to this syntax. But for a non-coder it is probably 
not the obvious syntax. And I don't think these quotes are necessary, 
since there is no new option or something after a blank. The value 
string has a natural end, that is the newline or carriage return. And 
you have to implement masking for at least the " and the masking char 
(perhaps '\').
Of course, the unmasked format hast also disadvantages: It is not 
possible to have an option with an whitechar at the begining or end 
since they are ignored (at least in my implementation). And it is not 
possible to have an value containing a '#', since this is the comment 
char. If that is a real problem, it would be possible to disable 
comments in a line with a definition but only accept lines with a '#' as 
first character as a comment.
I don't think this limitation with whitechars at the beginning or end of 
the value is that grave that it is really necessary to adopt quoted strings.

> and also any and any number of whitespaces between lines, keys, equal signs and
> values. (lib/cfglib.?pp has troubles with this, even it does not recognize any
> whitespace within a value)
> - These whitespaces are "corrected" to default (one space) when saving the config.
IIRC, my implementation handles this in a similar way as yours.

> In some ways this config lib might be more strict than the "old" ones: for
> example is
> str = foo bar
> wrong since the string was not embedded into double quotes although it contains
> whitespaces.
> 
> What's your opinion? Shall we use it for craft? Code as attachment.
Sorry, but the only _real_ advantage I see, is the speed. But (at least 
now) I don't think speed is that important, since the configurations are 
very small and are typically parsed once in a not really speed critical 
situation. I can't imagine, that a change of the configuration library 
would speed up craft radically.

cya arne