Jeff Schroeder wrote:
On Wed, Apr 7, 2010 at 1:02 PM, Dmitri Pal <dpal(a)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/