Boost logo

Boost :

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 ;)


> Thank you again, Hal

> Today is my TODO file clearly increase. :-)
> - Denis
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at