[ccan] Packaging what exists for ccan

[Tim Post]

Hi Ryan,

On Sun, 2009-03-01 at 20:20 -0800, Ryan Graham wrote:
> On Sun, Mar 1, 2009 at 12:03 PM, Tim Post <echo at echoreply.us> wrote:
> > Does anyone really use 'T' or 't' to indicate a boolean true in a
> > configuration file? I'd like to refactor this and other functions.
> 
> I don't follow the question... The code is only checking the first
> character of the string. It's not checking that said character is the
> only one in the string. And that's how it is documented to work. Are
> you proposing to make it more strict, so that it actually looks for
> the whole word?

Yes, I want to introduce some new keywords. T/t could also imply 'test',
meaning you want the program to try to run with the feature on, but not
error out if that feature just can't work.

Its a token I'm adding to help cure sanity problems when shipping a
default configuration. A program can run with factory safe values for
most things, while testing if other things work .. then write a
permanent configuration.

Various locality issues are also to be considered, so 'true' or 'false'
should be more easily configured. This makes loading a config slightly
more expensive, but nowhere near noticeably so.

> > So, if I do so .. should I just change the name of the module to
> > cfgparser or something similar? I also want to add some stuff, such as
> > the ability to:
> >
> > include /etc/myprog.d/startup.cfg
> 
> I happen to use iniparser in one of my projects, and while I don't
> have a use for includes at the moment, I can see how the feature could
> see some use..

It would be very handy for breaking up large configuration files. It
will take a bit of fiddling to make it work properly, especially if your
using iniparser to write a currently allocated configuration.

Likely, I will add include, and include_if. The first will error if the
file to include can not be found, the second would not.

I think, with those features added .. the module would save most people
from having to generate a parser using other tools.

> Keeping the same name would be convenient, since it's pretty
> descriptive. In this case, I'd see if the original author has an
> opinion.

Yes, I'm contacting him.

Cheers,
--Tim