[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Canonical pushes upstart into user session - systemd developer complains



On 2012-12-02 22:04:52 +0100, Wouter Verhelst wrote:
> On Sun, Dec 02, 2012 at 12:31:00PM +0100, Vincent Lefevre wrote:
> > On 2012-12-01 10:16:54 +0100, Wouter Verhelst wrote:
> > > On Fri, Nov 30, 2012 at 02:18:04AM +0100, Vincent Lefevre wrote:
> > > > At least for Perl, I can't see anything related to validation.
> > > 
> > > That's because validating an ini file is trivially easy:
> > > 
> > > the line is a comment line, which must start with a # after optional
> > > whitespace,
> > > or it is a section header, where all data must be surrounded by [],
> > > or it is a key-value pair, where the key must be one word and be
> > > separated by the value by a =
> > > 
> > > or it is invalid.
> > 
> > No, that's not sufficient.
> 
> Of course it is.

Perhaps for you. Not for me. Not for users who care about checking
errors in their files.

> > You may want relations between key-value pair. For instance, if you
> > have a line with a key "foo", then a line with a key "bar" must also
> > exist. Or a line with a key "number" must have a value that is a
> > number (more generally matching some regexp).
> 
> That's not validation of the format, that's validation of the data.

That's validation of the config file. This is what XML validation
does: it checks whether the file is valid according to some schema.

> I've never seen any config file with nested config blocks that didn't
> make the file more complex and less easy to understand.

Wrong. Nested blocks make config files easier to understand. Otherwise
for the same feature (e.g. conditionals), one would need things like
horrible state variables. For instance, think about redesigning a
procmailrc with the ini format...

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Reply to: