[SSSD] INI validation design thoughts

Jeff Schroeder jeffschroed at gmail.com
Wed Apr 7 20:16:17 UTC 2010


On Wed, Apr 7, 2010 at 1:02 PM, Dmitri Pal <dpal at redhat.com> wrote:
> Stephen Gallagher wrote:
>> On 04/07/2010 02:46 PM, Dmitri Pal wrote:
>> > See below
>> >> We really need to have
>> >> regex =
>> >> as an option. For example:
>> >> [ldap_uri]
>> >> type = field
>> >> vtype = string
>> >> regex = ldaps?://[\w\.]*
>> >> list = true
>> >> sep = , #How would we do space-separation? Should we even bother?
>> >>
>> > We can look into regex validation. Do not see big deal here.
>> > Will be a special function though. Can be added incrementally
>> > in a separate patch and handled as a separate task
>> > (within v1 validation functionality).
>>
>> > As for separators I imply that space is always a valid separator.
>> > Those would be additional separators we can check.
>>
>> I think it makes sense to NEVER use space as a separator, so that the
>> use of a separator then becomes explicit and unambiguous. (And it's
>> possible to add human-readable spaces around a separator)
>>
>> > Adding comma to the list for example would not generate an error and
>> > would parse list:
>> > foo bar baz
>> > the same way as
>> > foo,bar,baz
>> > or
>> > foo, bar, baz
>>
>> > There was a bug recently about the similar issue.
>> > Multiple separators for a list is already baked into the parsing logic.
>>
>>
>> My concern is for the possibility of options where you specify
>> foo bar, baz
>>
>> Because with your proposal, this is always translated to:
>> (foo, bar, baz), when what they really wanted was (foo bar, baz)
>>
>> Right now in the SSSD there aren't any cases like this, but we're trying
>> to build libini_config for general consumption. I don't think we're out
>> of line requiring an explicit separator. Additionally, we can add
>> another rule that whitespace surrounding a separator is not included in
>> the value.
>>
>> So name = value1\s\s\s,\svalue2 would become ('value1', 'value2') and
>> not ('value1 ', ' value2')
>>
>
> I kind of disagree with the whole approach.
> If you want spaces inside the value you need to make the string quoted.
>
> Something like
>
> value = "fist value", "second value"

JSON != ini. As a format, ini allows spaces just like Stephen posted.
If you want something like JSON perhaps the config format should
indeed be JSON or YAML. However, I think Stephen is correct in that:
key = value1, value two, valueTHREE

should evaluate to this in python syntax:
key = ("value1", "value two", "valueTHREE")

What you proposed seems counter-intuitive.

> This is currently not supported but would be easy to add when needed.
> But again we are talking about the ini files and explicitly multi value
> lists.
> It is not a good practice to have spaces in the multi value lists anyways.
> And I do not want people to encourage doing it.
> In case of single value the inner spaces are preserved but leading
> and trailing ones are trimmed.

Explicit is always better than implicit. The reverse is poor design in
most cases. Take a look at places where this caused problems in the
past *I'm looking at you php's magic quotes*.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com



More information about the sssd-devel mailing list