Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Hal Finkel (half_at_[hidden])
Date: 2010-11-29 12:49:17

On Mon, 2010-11-29 at 18:51 +0300, Denis Shevchenko wrote:
> On 29.11.2010 18:16, Hal Finkel wrote:
> > Do you just mean a kind of parse-time validation framework (where the 
> > parser checks that an e-mail setting looks like a valid e-mail 
> > address, etc.)? 
> Yes.
> > That can be useful, but make sure that you can get warnings instead of 
> > errors (for e-mail this is important).
> Hm... But what if user inputs invalid e-mail address by mistake? Why 
> should this be a warning and not a error?

Many times it should be an error, but sometimes it should be a warning.
In some sense, it depends on how robust your validation routine is (does
it except '+' with a mailbox name, or multiple mailboxes, etc.), but
sometimes people use a custom syntax for private (internal) messaging,
and since, in the end, the e-mail address is just an uninterpreted
string being passed to the SMTP server (or similar), the user sometimes
needs the ability to use private extensions.

> > path checking is also useful, but failure to exist is not always an 
> > error, sometimes the application can create a missing directory...
> Ops, that's what I do not think (I thought about creating a file, but 
> not about creating a directory)... Thank you very much.
> > In short, the behavior must be customizable. 
> Thanks, I'll remember this.
> > ... the functionality that I think is missing from configuration-file 
> > parsing libraries is a change-event-based interface to support runtime 
> > reloading.
> Do you mean an "automatic" reparsing in case the configuration file has 
> been modified? Hm, it's interesting...

Generally, a reload is externally triggered (via a signal or some
administrative interface). Reloading any time the file changes is a bad
idea, since it could be in an inconsistent state. In my opinion, just
provide a reload function.

> > Then when user requests the configuration be reloaded, the library 
> > only sends change events for those things which have actually changed 
> > (this requires matching named sections, since the order may have 
> > changed). I should have the option of reusing the same event loop for 
> > initial loading as well. 
> Yes, you are right, this is a good proposal.
> 

I'm glad you like it ;)

 -Hal

> Thank you again, Hal

>  Today is my TODO file clearly increase. :-)
> 
> - Denis
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost