[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Wed Apr 7 20:43:39 UTC 2010


Jeff Schroeder wrote:
> 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.
>
>   

Ok I did some tests and looked at the code.
I was wrong. My memory failed me :-)

Here is how it works now.

* Space is not counted as a separator
* Spaces (and tabs) are trimmed around separators
* Inner spaces are preserved
* There is no way to preserve leading or trailing spaces in a multi
value list

So I think we are Ok on this point.
Note: The function does not prevent you from specifying a space as a
separator so if you want it be a separator you can.

>> 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*.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list